Enabling from S-mode in a RVA20/RVA22-compatible way

[sorear]

The current draft profiles spec requires HADE=0 behavior in both RVA20 and RVA22, at least in the initial environment, which means that a SEE/bootloader must initialize HADE to 0 before starting a supervisor if it wants to be able to run RVA20 and RVA22 compliant supervisors. How, then, is a supervisor that wants HADE=1 to get it? Are we expecting to require a new SBI call (I would prefer not), or to expose HADE in senvcfg?

[ved-rivos]

So the senvcfg is the environment configuration for U-mode and since virtual memory system configurations are for U-mode the HADE is not added to senvcfg. The menvcfg is the environment configuration for S mode and is expected to be setup by the M-mode depending on the supervisor that it needs to execute. This should be similar to other configurations in menvcfg such as PBMTE and SSTC.

[semihalf-kardach-stanislaw]

AFAIK currently at least in OpenSBI the PBMTE is pre-configured by it (https://github.com/riscv-software-src/opensbi/blob/b6e520b2a836cd7cc8dc99c25a21a470e8589888/lib/sbi/sbi_hart.c#L134). There is no way to change it. So the original question still stands - is an SBI call required?
To add another aspect - how would a supervisor SW (say the Linux kernel) query the state of HADE? Sounds like another SBI call to me. It would be simpler if senvcfg would have HADE as a copy (at least RO) of menvcfg.HADE. That would save an SBI call during the startup.

[sorear]

The base privilege spec requires software to zero the high bits of PTEs, and RVA20 does not forbid implementation extensions that use the high bits of PTEs, so there's no compatibility issue with forcing PBMTE=1 in opensbi without software input. (This raises the question of why PBMTE exists at all, but it's not really on topic here.)

RVA20 does forbid implementations from handling A/D bits without a page fault (via the "Ssptead" mandatory pseudo-extension), so if HADE were set to 1 in the block of code you just linked, opensbi would no longer provide the RVA20 profile.

I've been convinced by #11 that putting HADE in senvcfg doesn't make sense, so my issue at this point is mostly confusion about what compatibility properties are expected to exist between different-year RVA profiles. If RVA22 and RVA24 have opposite requirements for HADE and are mutually exclusive for SEEs to support, then there's no issue on this end, but a communication issue is created for supervisors that want to support "RVA20 or later", since there's nothing in the profile spec to distinguish things that are likely to change in future profiles from things that aren't. If RVA24 support implies RVA20 support in a SEE, then supervisors can easily support "RVA20 or later", but either RVA20 needs to drop the HADE=0 requirement or RVA24 needs a supervisor opt-in mechanism for HADE.

[adurbin-rivos]

RVA20 says Ssptead is mandatory, however RVA23 is expected to have Svadu or Ssptead as an option.

[sorear]

OK. I assume you mean RVA23S64, not a hypothetical RVA23M64, so the profile describes only behavior observable in S-mode.

Does anyone else see the fragmentation issue I'm trying to bring to attention here, with RVA20 SEEs making a guarantee to supervisor software that future SEEs won't be able to uphold?

[adurbin-rivos]

Correct on RVA23S64. RVA23 profiles are expected to be a major release where RVI is expecting ISVs to build solutions around: https://lists.riscv.org/g/tech-profiles/message/48 That said, any kernel has the ability to deal with this optional behavior, but it's ultimately up to the vendor for what they want to decide. It's expected Linux can and will be able to deal with both options. In fact, it already does empirically since QEMU's default behavior acts like Svadu is there. And Linux is running on RISC-V HW implementations that does do minor faults for PTE A/D bit updates.

[sorear]

I think that it would be a good thing if we documented the set of things that "it is expected Linux can and will be able to deal with".

A week ago I thought that baseline was called RVA20S64, but because of Ssptead RVA20S64 is not a description of QEMU's default behavior and it won't describe future SEEs, so do we need a new name and specification for the baseline?

[adurbin-rivos]

Well, this change is for the RISC-V spec proper so I don't think expectations on Linux should be in spec, but it's not my call in the end.

I'm not sure what you mean by a baseline, but if an OS was written targeting RVA20S64 and only decided to support Ssptead somehow it would still be possible for a system that supported Svadu to be configured to work in that case. While the profiles try to be prescriptive, it does not necessarily follow that an OS strictly and explicitly only supports things in there. That's at least how I see.