search

riscv / riscv-profiles

RISC-V Architecture Profiles
Creative Commons Attribution 4.0 International
119 stars 33 forks source link

RVA23 clarification request: `Ssstrict` #173

Closed a4lg closed 4 months ago

a4lg commented 5 months ago

The Ssstrict extension in RVA23 seems good for properly restricting reserved encodings. But if possible, I'm happy if "supervisor-mode trap handler" is clarified further.

I mean, I think this "supervisor-mode trap handler" if H (hypervisor) is implemented means both HS-mode and VS-mode trap handlers (because they both operate in the supervisor-mode) but if this point is clarified, it will make hypervisor developers happy (e.g. enabling software emulation of reserved instructions in the hypervisor level).

kasanovic commented 4 months ago

Ssstrict definition applies to the execution environment claiming to be RVA23 compatible -which must have the hypervisor extension. That execution environment will take a contained trap to supervisor-mode (however that trap is implemented, including, but not limited to, emulation/delegation in the outer execution environment). Ssstrict (and all the other RVA23 mandates and options) do not apply to any guest VMs run by a hypervisor. An RVA23 hypervisor can provide guest VMs that are also RVA23-compatible but with an expanded set of emulated standard instructions. An RVA23 hypervisor can also choose to implement guest VMs that are not RVA23 compatible (e.g., lacking H, or only RVA20).

a4lg commented 4 months ago

Fair enough.

My point is, if the hypervisor side can benefit from the Ssstrict extension (capture the trap from the guest), that enables we can guarantee that we can emulate instructions using the hypervisor, even if the guest is not RVA23-compatible.

That execution environment will take a contained trap to supervisor-mode (however that trap is implemented, including, but not limited to, emulation/delegation in the outer execution environment).

From my view, it seems your answer to my point is, "yes".