First proposal for H-extension support for RISC-V Worlds. by ruuddw · Pull Request #19 · riscv/riscv-worlds

ruuddw · 2026-02-26T19:34:19Z

First proposal for the newly proposed Fast-Track to add support for virtualization (H-extension).
The Shwdeleg/Svswid extensions add another delegation level to match the additional level of privilege hierarchy that the H extension introduces. Two HS-mode registers (that are not visible to VS) are added, called hlwid and hwiddeleg. Another HS-mode register called vslwid is added, which is also accessed via the slwid CSR addres in VS-mode.

Signed-off-by: Ruud Derwig <Ruud.Derwig@synopsys.com>

andrewdellow

I was wondering why you added hlwid and vslwid - I was expecting just the addition of hlwid, such that

S (no H extension) or HS (with H extension) transactions are tagged with mlwid,

When H is supported and V = 1, VS transactions tagged with hlwid

U/VU transactions tagged with slwid

I then suppose that when H is enabled, mwiddeleg then applies to hlwid, instead of slwid, and we need another CSR set from HS :– hwiddeleg that applies to slwid ?

ruuddw · 2026-03-02T17:29:13Z

Right, the vslwid is a bit special. It's like other "vs" registers introduced by the H extension:

Furthermore, several virtual supervisor CSRs (VS CSRs) are replicas of the normal supervisor CSRs. For example, vsstatus is the VS CSR that duplicates the usual sstatus CSR.
When V=1, the VS CSRs substitute for the corresponding supervisor CSRs, taking over all functions of the usual supervisor CSRs except as specified otherwise. Instructions that normally read or modify a supervisor CSR shall instead access the corresponding VS CSR. When V=1, an attempt to read or write a VS CSR directly by its own separate CSR address causes a virtual-instruction exception. (Attempts from U-mode cause an illegal-instruction exception as usual.) The VS CSRs can be accessed as themselves only from M-mode or HS-mode.

Rationale for it is in the PoW, probably a note should be added in this spec to explain as well. This is the relevant PoW rationale bullet:

For hypervisor VM load/store instructions (hstatus.HU=1) there is no option for software to reprogram slwid before the HLV.x instruction.

If the hypervisor could always reprogram the WID to be used for VU (also when the hypervisor itself needs to access the VU memory with the VU WID, not the S or U WID) we could do without vslwid (with some extra WID switching software). But for hstatus.HU=1, it needs to be done by the hardware.
This was discussed about a year ago: https://lists.riscv.org/g/security/message/1159

yloisel · 2026-03-05T16:44:39Z

src/worlds.adoc

+* The *Shwdeleg/Svswid* extensions add another delegation level to match the additional
+  level of privilege hierarchy that the H extension introduces. Two HS-mode
+  registers (that are not visible to VS) are added, called `hlwid` and `hwiddeleg`.
+  Another HS-mode register called `vslwid` is added, which is also accessed


vslwid is the replica CSR of the S-mode slwid CSR ?

And behavior similar to what is described in Priv spec, section 21.2:

When V=1, the VS CSRs substitute for the corresponding supervisor CSRs, taking over all functions of the usual supervisor CSRs except as specified otherwise. Instructions that normally read or modify a supervisor CSR shall instead access the corresponding VS CSR. When V=1, an attempt to read or write a VS CSR directly by its own separate CSR address causes a virtual-instruction exception. (Attempts from U-mode cause an illegal-instruction exception as usual.) The VS CSRs can be accessed as themselves only from M-mode or HS-mode.

yloisel · 2026-03-05T16:47:31Z

src/worlds.adoc

+| `XLEN` | `hlwid` | WARL for HS | `???` | WID value used for lower privilege
+modes than HS-mode with the optional Svswid extension (i.e., VS/VU-mode).
+ `Ceil(Log~2~NWorlds)` LSBs are used, others are zero.
+| `XLEN` | `vslwid` | WARL for HS | `???` | With the Svswid extension, this CSR


WARL for HS and VS ?

yloisel · 2026-03-05T16:47:48Z

src/worlds.adoc

+modes than HS-mode with the optional Svswid extension (i.e., VS/VU-mode).
+ `Ceil(Log~2~NWorlds)` LSBs are used, others are zero.
+| `XLEN` | `vslwid` | WARL for HS | `???` | With the Svswid extension, this CSR
+ is the virtualization shadow register of the slwid register. In HS-mode this


is the replica register of the slwid register

yloisel · 2026-03-05T16:49:17Z

src/worlds.adoc

+modes than HS-mode with the optional Svswid extension (i.e., VS/VU-mode).
+ `Ceil(Log~2~NWorlds)` LSBs are used, others are zero.
+| `XLEN` | `vslwid` | WARL for HS | `???` | With the Svswid extension, this CSR
+ is the virtualization shadow register of the slwid register. In HS-mode this


in HS and in VS modes, this ...

yloisel · 2026-03-05T16:51:34Z

src/worlds.adoc

+VS-mode on a hart is platform-specific.
+
+`hwiddeleg` is always a subset of `mwiddeleg`. Attempts to authorize a WID in
+`mwiddeleg` that is not authorized in `mwiddeleg` will fail - the


typo: in hwiddeleg

yloisel · 2026-03-05T16:54:03Z

src/worlds.adoc

+will be implicitly de-authorized in `hwiddeleg` also.
+
+If `hwiddeleg` is zero (which may happen even if non-zero values are written to
+it, see the previous paragraph), the Svswid extension is disabled, in which case


I don't understand why Svswid extension is disabled if hwiddeleg is empty, as Svswid extension is claimed to add the hlwid CSR.
It should be possible anyway to assign a WID to VS and VU (the same one) using the hlwid CSR, as it is written 2 lines after.

yloisel · 2026-03-05T16:55:30Z

src/worlds.adoc

+to determine the actual configuration retained by the implementation.
+
+The Svswid extension adds the HS-mode read-write `hlwid` CSR, which
+sets the WID used for VS-mode and if not further delegated for VU-mode. The `hlwid`


So Svswid extension is used to have a VS and VU WID (set by hlwid) distinct from the HS WID (set by mlwid), whether hwiddeleg is empty/enabled or not

yloisel · 2026-03-05T16:57:21Z

src/worlds.adoc

+`hwiddeleg` register represents a set of WIDs as a bit vector with
+WID _i_ represented by bit _i_ of the register.  The `hwiddeleg` CSR
+is a WARL register where each bit that can be set indicates a WID that
+is delegated to VS-mode. The set of worlds that can be delegated to


indicates a WID that can be set for VU mode by VS mode

yloisel · 2026-03-05T17:04:27Z

src/worlds.adoc

+sets the WID used for VS-mode and if not further delegated for VU-mode. The `hlwid`
+field is WARL that can contain Ceil(Log~2~NWorlds)-1:0 writable bits.
+
+If an unauthorized WID (per the `hwiddeleg` list) is written to `hlwid`, then


hwiddeleg constrains the values in vslwid, not in hlwid (these ones are constrained by mwiddeleg)

yloisel · 2026-03-05T17:07:55Z

src/worlds.adoc

+To allow for a hypervisor to set or context switch the VS-mode `slwid` CSR, 
+the `vslwid` shadow register is defined. In HS-mode this register can be 
+programmed to set the effective WID of VU mode. In VS-mode it is accessed via
+the `slwid` CSR address.


this paragraph is redundant with description made above

yloisel · 2026-03-05T17:16:51Z

Seems to be some confusion about the Svswid extension which is claimed to add the hlwid CSR but which is also blocked if there's no delegation to VS mode. So looks like Svswid should be about adding vslwid CSR

First proposal for H-extension support for RISC-V Worlds.

94f182a

Signed-off-by: Ruud Derwig <Ruud.Derwig@synopsys.com>

andrewdellow reviewed Mar 2, 2026

View reviewed changes

yloisel reviewed Mar 5, 2026

View reviewed changes

Conversation

ruuddw commented Feb 26, 2026

Uh oh!

andrewdellow left a comment

Choose a reason for hiding this comment

Uh oh!

ruuddw commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yloisel Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yloisel commented Mar 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yloisel Mar 5, 2026 •

edited

Loading