Ssptead forward compatibility

[sorear]

NOEL-V (mandatory), QEMU (mandatory), spike (optional), likely other current implementations provides the "CAS(oldPTE, oldPTE|A|D)" semantics during page table walks. Is this forbidden by Ssptead and thus RVA20 and RVA22? Is automatic maintenance of A/D bits a deprecated feature in general, or only in A-profiles?

If it is forbidden (and as such NOEL-V and QEMU need retroactive changes to be compatible with RVA20), what is the path for returning it? Presumably an S-mode accessible CSR, since if the state were M-mode only the SEE would not be able to start up in a RVA20 compliant state.

[pdonahue-ventana]

If it is forbidden (and as such NOEL-V and QEMU need retroactive changes to be compatible with RVA20), what is the path for returning it?

https://github.com/riscv/riscv-svadu/

[sorear]

Thanks. Revising my concern to:

I am under the impression RVA20 is supposed to be a formalization of existing practice / the "least common denominator" of common RV64GC implementations designed to run multiuser operating systems. The current SvXX spec and the SvXX spec in effect for RVA20 (1.11) both provide HADE=1 behavior as an option, and HADE=0 behavior for "simple implementations" only. It seems undesirable that best effort implementations of the 2020-era specs are not going to qualify for RVA20, including the qemu versions that most 2020-era supervisors were tested against.

ETA: A boot environment compatible with multiple profile versions will need to initialize menvcfg.HADE=0, but this isn't writable from (H)S-mode, so a new SBI call would need to be added. Are we generally trying to avoid that?

[sorear]

Improved question: assuming that Svadu reaches ratification in time for RVA24S64, what is RVA24 expected to say about A/D bit maintenance? menvcfg.HADE itself is out of scope for RVA*S* because it's an M-mode state bit, but what will S-mode code see in 2024, and what should S-mode code written today expect to see in the future / what should S-mode code do to maximize the chances that it will be compatible with RVA24S64?

1. A/D bits are maintained automatically in page table entries, as allowed by the privileged spec. (In other words, HADE=1 semantics. This is an incompatible break from RVA20 and RVA22, but profiles were never expected to be monotonic.)
2. When a supervisor starts, A/D bits cause a page fault when clear for RVA20 and RVA22 compatibility, but an SBI call can be used to switch to a mode where A/D bits are maintained automatically.
3. A/D bits either cause a page fault when clear or are maintained automatically, at the platform implementor's discretion. (Unconstrained privileged spec behavior.)
4. The platform decides what behavior to use for A/D bits based on out of band information about the supervisor that will eventually run at the end of the boot process. (This is my reading of Enabling from S-mode in a RVA20/RVA22-compatible way riscvarchive/riscv-svadu#10 (comment) although I am very concerned about the boot protocol implications of this.)

This needs to be answered now only to the extent it affects S-mode code written now.

[kasanovic]

The intent is to include Svadu in RVA23 as an option but disabled by default at launch of supervisor execution environment (i.e., your option 2).

[kasanovic]

It is concerning (or maybe reassuring?) that QEMU effectively had HADE=1 by default, but quite a few silicon systems shipped with HADE=0, and no one seemed to notice until recently. A question is if earlier silicon shipped with HADE=1?

The plan is to remove the HADE=1 text from base priv arch in 1.13 and move that text into Svadu.

[kasanovic]

I believe this has been addressed so closing.