On 2021-11-17 10:33 p.m., Bill Huffman
So if I set up indexes on a ff gather so
that I ensure the first one is legal while the rest access
pages I want to probe, how does the higher privilege software
know I learned about all those pages?
First there is currently no ff gather.
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.
A substantial effort to essentially be thrown away on the next
try to discover the page mappings.
This was another reasons that ff gather was rejected. It does not
play well with the parallel load behaviour that is allowed for
I suppose an implementation could trap on
any element if it started with vstart=0 and only complete with
zero values loaded if vstart>0.
Then the higher privilege software could
cooperate and restart even if the element failed for these
instructions with vstart pointed at the failed element.
But I don’t think that was the expected
Not sure I follow this.
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.
Indeed, the OS can emulate the set vl length behaviour. It would
still be an optimization even in the guard page scenario.
On Behalf Of David Horner
Sent: Wednesday, November 17, 2021 10:12 PM
To: Jonathan Behrens <behrensj@...>
Cc: Andrew Waterman <andrew@...>; vector
Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector
Extension post-public review updates - fault flagging
The trap if first address bad is
The other are not specified in the vector
extension , but
1. the counter is part of the
generalized performance spec.
2. Always trap but allow resume is an
3. Dynamically limit vl=1 is a
hypothetical extension that could have a csr to manage.
Obviously these could be defined as
part of the privilege spec and the VM guys probably want
to nail them down exactly.
I prefer minimalistic S and M support
with least specs to allow implementations latitude.
On Wed., Nov. 17, 2021, 21:33 Jonathan
Behrens, <behrensj@...> wrote:
Are the mechanisms you mentioned
hypothetical future ISA extensions, or something
included in the current vector extension? In
particular, I don't see anything about M-mode and/or
HS-mode requesting a trap if too many non-faulting
fault-first-load instructions are executed which
On Wed, Nov 17, 2021 at 9:19 PM
David Horner <ds2horner@...>
that should have been "The HS is in
control, it can "leak" or not as it sees fit"
On 2021-11-17 8:45 p.m.,
Andrew Waterman wrote:
On Wed, Nov 17, 2021 at
5:41 PM Jonathan Behrens <behrensj@...>
On Wed, Nov
17, 2021 at 4:19 PM Jonathan
security concern was being
able to probe addresses to
find accessible regions
without free of being
killed on touching a
prohibited region. It was
noted that this is still
present even for
unit-stride in supervisor
mode when using
translation to arbitrarily
probe supervisor physical
space. However, I believe
these security concerns
are manageable through
control mechanisms at
higher privilege levels
someone say what these
control mechanisms are? In
particular, it seems like
a VS-mode guest operating
system could probe the
entire guest physical
address space using
without triggering any
intervention from HS-mode
being obtuse, but I'm having
trouble understanding why this
specific case is a concern:
it's within VS-mode's purview
to know anything and
everything about the guest
physical address space. (The
situation is materially
different than S vs. U,
because those two share a VA
space, whereas VS' GPA space
is disjoint from HS' VA
address space that the hypervisor
tells the guest about may not match
the one installed in hgatp. For
instance, some pages of the guest's
memory might be marked copy-on-write
or swapped out to disk. Or a
particular device may supposedly be
mapped into the guest VM, but
actually just be an unmapped region
so the host can trap-and-emulate any
accesses to it. Even today it is
possible for a guest VM to
indirectly learn that these things
might be happening, but directly
being able to check whether a page
is mapped adds a new level.
Yeah, agreed that
detecting paged-out pages is a similar
The VS having this awareness can be very
It allows the OS to better manage its resources.
It can switch to handling other supervisory
actions while that data is paged/staged in.
Never the less, the control mechanisms I
previously mentioned apply here as well.
The HS is in control, it can "leak" or
not as it sees fit.
(Though I think COW is
not relevant here, since we're only
talking about load instructions.)