The RISC-V hypervisor (H) extension virtualizes the supervisor-level architecture to support the efficient hosting of guest operating systems atop a type-1 or type-2 hypervisor cite:[riscv-priv-spec]. The hypervisor extension is generally orthogonal to CHERI; the main requirements, when integrating with {cheri_base_ext_name} and {cheri_default_ext_name}, is that address CSRs added for hypervisors are extended to CLEN size so that they are able to hold capabilities. The remainder of this chapter describes these changes in detail.
The hstatus register operates as described in cite:[riscv-priv-spec] except for the VSXL field that controls the value of XLEN for VS-mode (known as VSXLEN).
The encoding of the VSXL field is the same as the MXL field of misa. Only 1 and 2 are supported values for VSXL. When the implementation supports {cheri_base_ext_name} (but not {cheri_default_ext_name}), then hstatus's VSXL must be read-only as described in [mstatus] for [mstatus].SXL. When the implementation supports both {cheri_base_ext_name} and {cheri_default_ext_name}, then VSXL behaves as described in [mstatus_hybrid] for mstatus.SXL.
The VSBE field determines controls the endianness of explicit memory accesses from VS-mode and implicit memory accesses to VS-level memory management data structures. VSBE=0 indicates little endian and VSBE=1 is big endian. VSBE must be read-only and equal to MBE when the implementation only supports {cheri_base_ext_name}. VSBE is optionally writeable when {cheri_default_ext_name} is also supported.
The henvcfg register operates as described in the RISC-V Privileged Specification. A new enable bit is added to henvcfg when the implementation supports {cheri_default_ext_name} as shown in Hypervisor environment configuration register (henvcfg).
The CHERI Register Enable (CRE) bit controls whether explicit access to CHERI registers is permitted when V=1. When henvcfg.CRE=1 and [menvcfg].CRE=1 and [mseccfg].CRE=1, CHERI registers can be read and written by VS-mode and VU-mode. When henvcfg.CRE=0, CHERI registers are disabled in VS-mode and VU-mode as described in [section_cheri_disable].
The reset value is 0.
Bit 28 of hedeleg now refers to a valid exception and so can be used to delegate CHERI exceptions to virtual supervisor mode.
The htval register operates as described in cite:[riscv-priv-spec].
htval is updated following the same rules as [mtval] for CHERI exceptions which are taken in HS-mode.
The htval2 register is an HSXLEN-bit read-write register, which is added as part of {cheri_base_ext_name} when the hypervisor extension is supported. Its CSR address is 0x64b.
htval2 is updated following the same rules as [mtval2] for CHERI exceptions, load page fault and store/AMO page fault exceptions which are taken in HS-mode.
The fields are identical to [mtval2] for CHERI exceptions.
The vsstatus register operates as described in cite:[riscv-priv-spec] except for the UXL field that controls the value of XLEN for VU-mode.
The encoding of the UXL field is the same as the MXL field of misa. Only 1 and 2 are supported values for UXL. When the implementation supports {cheri_base_ext_name} (but not {cheri_default_ext_name}), then vsstatus.UXL must be read-only as described in [mstatus] for [mstatus].UXL. When the implementation supports both {cheri_base_ext_name} and {cheri_default_ext_name}, then UXL behaves as described in [mstatus_hybrid] for mstatus.UXL.
The vstvec register is as defined in cite:[riscv-priv-spec]. It is the VSXLEN-bit read/write register that is the VS mode’s version of the supervisor register [stvec].
The vstvecc register is a renamed extension of vstvec that is able to hold a capability. Its reset value is the [infinite-cap] capability.
The vsscratch register is as defined in cite:[riscv-priv-spec]. It is a VSXLEN read/write register that is VS-mode’s version of supervisor register [sscratch]. vsscratch is extended into vsscratchc.
The vsscratchc register is a renamed version of vsscratch that is able to hold a capability.
{TAG_RESET_CSR}
It is not WARL, all capability fields must be implemented.
The vsepcc register is a renamed extension of vsepc that is able to hold a capability. Its reset value is the [infinite-cap] capability.
As shown in [CSR_exevectors], vsepcc is an executable vector, so it need not be able to hold all possible invalid addresses. Additionally, the capability in vsepcc is unsealed when it is installed in [pcc] on execute of an [SRET] instruction. The handling of vsepcc is otherwise identical to [mepcc], but in virtual supervisor mode.
The vstdc register is a capability width read/write register that is VS-mode’s version of supervisor register [stdc]. This register is only present when the implementation supports {cheri_default_ext_name}.
{TAG_RESET_CSR}
{REQUIRE_CRE_CSR}
The vstval register is a VSXLEN-bit read-write register.
vstval is updated following the same rules as [mtval] for CHERI exceptions, load page fault and store/AMO page faults which are taken in VS-mode.
The vstval2 register is a VSXLEN-bit read-write register, which is added as part of {cheri_base_ext_name} when the hypervisor extension is supported. Its CSR address is 0x24b.
vstval2 is updated following the same rules as [mtval2] for CHERI exceptions which are taken in VS-mode.
The fields are identical to [mtval2] for CHERI exceptions.
The hypervisor extension defines several integer load and store instructions (such as [HLV_W], [HSV_W] and [HLVX_WU]) that transfer the amount of integer data described in cite:[riscv-priv-spec] between the registers and memory as though V=1. These instructions change behavior depending on the CHERI execution mode although the instruction’s encoding remains unchanged.
When in {cheri_cap_mode_name}, the hypervisor load and store instructions behave as described in [section_existing_riscv_insns]. In {cheri_int_mode_name}, the instructions behave as described in cite:[riscv-priv-spec] and rely on an x register operand providing the effective address for the memory access; the capability authorizing the memory access is [ddc].
The exception cases remain as described in [section_existing_riscv_insns] regardless of the CHERI execution mode.
Hypervisor virtual-machine load ([HLV.C]) and store ([HSV.C]) capability instructions read or write CLEN bits from memory as though V=1. These instructions change behavior depending on the CHERI execution mode although the instruction’s encoding remains unchanged.
When in {cheri_cap_mode_name}, the hypervisor load and store capability instructions behave as described in [section_existing_riscv_insns]. In {cheri_int_mode_name}, the instructions behave as rely on an x register operand providing the effective address for the memory access and the capability authorizing the memory access is [ddc].