1. Messages
  2. RISC-V Vector Extension post-public review updates - fault flagging

Re: RISC-V Vector Extension post-public review updates - fault flagging

Bruce Hoult
 

On Thu, Nov 18, 2021 at 5:07 PM David Horner <ds2horner@...> wrote:

But if there were, the vl would need to be truncated to the first in sequence that faulted.

That would potentially require back tracking by the handler from the element load that faulted first, to each of the earlier loads in the list.

Simple implementations could simply execute it sequentially. Or have the trap handler execute the loads sequentially if any of them fault.

A substantial effort to essentially be thrown away on the next try to discover the page mappings.

We don't care how slowly malicious code runs.

This was another reasons that ff gather was rejected. It does not play well with the parallel load behaviour that is allowed for loads.

It plays just as well as any gather does, in the absence of faults.

Faulting is very much NOT expected behaviour. You're probably about to terminate the program anyway, or drop into the debugger. The main requirement is that the user can see which iteration of their loop would have failed if the code had been left as scalar instructions instead of auto-vectorised.

If FF gather were implemented the designer would probably always trap on any fault.

If the OS determines the virtual addresses are legitimate it could preemptively page-in/allocate the requested addresses.

If any of the addresses are illegal/illegitimate it could certainly mark this application suspect and escalate its management to whatever security features are enabled.

This is a legal option for load sequential first fault but we have at most 2 pages/regions to deal with.

One region, but it could be many page table entries, given sufficiently long vector registers -- up to 17 with 65536 bit VLEN and LMUL=8.
Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.