[RISC-V] [tech-virt-mem] Fault type when PTE reserved bit is set


should an OS person weigh in on this?

I asked previously about COW and was told a reserved bit could be used.

---------- Forwarded message ---------
From: Greg Favor <gfavor@...>
Date: Fri, Feb 26, 2021 at 11:11 AM
Subject: Re: [RISC-V] [tech-virt-mem] Fault type when PTE reserved bit is set
To: <tech-virt-mem@...>, Allen Baum <allen.baum@...>
Cc: Richard Trauben <rtrauben@...>, swallach <steven.wallach@...>

Copy-on-write is a popular thing and takes the form of a page fault.


On Fri, Feb 26, 2021 at 11:09 AM Allen Baum <allen.baum@...> wrote:
Not that I will disagree with wanting just one way of reporting this, and not allowing optional behavior, but isn't there a valid use case for recoverable access exceptions?
That's how copy-on-write works.
 Is that no longer used, or is it done a different way on modern systems and I'm showing my age? 

On Fri, Feb 26, 2021 at 10:54 AM Richard Trauben <rtrauben@...> wrote:
Hi All,

In my opinion, we will not recover from a malformed pte, so Violation (INSTEAD of fault) seems more appropriate.


On Fri, Feb 26, 2021 at 10:48 AM swallach <steven.wallach@...> wrote:
here is my 2cents

a fault is an action  that can be recovered from and processing continue (eg page fault)

and access violation is something,  then in general you can NOT recover from

i will defer to others to pick/chose the appropriate term.  but there should be a distinction  imho


On 2/26/2021 10:42 AM, Jonathan Behrens wrote:
Could you clarify what concern would be addressed by specifying that using
those reserved bits cause a specific trap?

It would just seem to be an unnecessary degree of freedom in the spec.

Now, for example, the Sail model would have to presumably be
parameterized for which fault should be returned in this situation,
for no apparent benefit (other than maintaining backwards compatibility
with implementations that already do both).

The architecture test case for this situation would now have two valid
signatures instead of one, and Allen has been commenting for a while
how that would require big changes in the architecture testing framework.

If software is using "try setting it and see if it traps" as a
discovery mechanism, now that software is more complicated because it
needs to handle either type of fault there.

...etc.  I expect this type of issue will be more noticeable now that
we're proposing to start actually using these bits.


WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.


Jonathan Behrens <behrensj@...>

On Tue, Mar 2, 2021 at 11:04 AM mark via lists.riscv.org <markhimelstein=riscv.org@...> wrote:
should an OS person weigh in on this?

I asked previously about COW and was told a reserved bit could be used.

I think you might be confusing the "reserved for software" (RSW) bits in the PTE with the "Reserved" bits. The former are bits 8 and 9 in a PTE, while the latter are bits 54-63 in Sv39/Sv48 and don't exist in SV32.

Operating systems will frequently use one of the reserved for software bits to track whether a page is COW or not, and hardware is required to ignore whether those bits are set. By contrast, software is currently prohibited from setting any of the Reserved bits, with currently unspecified results if it does anyway (the subject of this thread being to instead define the behavior as triggering a page fault if the PTE accessed non-speculatively).


PS: this isn't the first time I've seen confusion over the reserved vs. reserved for software, so it might be worth thinking about if there is a way to make things clearer.