- RISC-V Vector Extension post-public review updates - fault flagging
Re: RISC-V Vector Extension post-public review updates - fault flagging
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
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 email@example.com to automatically receive all group messages.