[libre-riscv-dev] Spectre mitigation stratagies

[Luke Kenneth Casson Leighton]

On Fri, Jan 11, 2019 at 5:36 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

t for LD/ST.
> > why would other operations be affected?
> >
> if a speculated instruction is using the last of some resource (alu,
> register read port, etc.) and it prevents a non-speculative instruction
> from executing, then the speculative instruction is canceled, you can tell
> that they've been run because the non-speculative instruction took longer
> to start. that delay could be data-dependent (like a predication mask in sv
> or something).

 but.... that's crazy!  that's going to affect *everything*!
interrupts, exceptions, predication, branches, LD/ST - there's hardly
a single part of the design that's going to be massively impacted,
bringing performance to an absolute stand-still!

 one "solution" would be to massively over-spec the shadow capability,
such that absolutely all and any new instructions are absolutely
guaranteed to never hit a resource limit.

 another is to say, "ok, so there's a new non-speculative instruction
being issued: *right now*, it *has* to have absolute top priority, in
this instruction cycle."  that means immediate cancellation of the
newest speculated instruction using the resource that the
non-speculative one needs.

 ... however, that trick won't work on exceptions, interrupts or
predication, leaving "over-resourcing" and drastically cutting back on
the instructions issued per clock.

 none of which is really acceptable.

 there has to be a better way, such as identifying (programmatically)
the resources which are vulnerable, and limiting the issue and
speculation during their operation.

l.