The hstatus register is an HSXLEN-bit read/write register formatted as shown in Hypervisor status register (hstatus) when HSLEN=32 when HSXLEN=32 and Hypervisor status register (hstatus) when HSXLEN=64. when HSXLEN=64. The hstatus register provides facilities analogous to the mstatus register for tracking and controlling the exception behavior of a VS-mode guest.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hstatusreg-rv32.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hstatusreg.edn[]

The VSXL field controls the effective XLEN for VS-mode (known as VSXLEN), which may differ from the XLEN for HS-mode (HSXLEN). When HSXLEN=32, the VSXL field does not exist, and VSXLEN=32. When HSXLEN=64, VSXL is a WARL field that is encoded the same as the MXL field of misa, shown in [misabase] on page 19. In particular, an implementation may make VSXL be a read-only field whose value always ensures that VSXLEN=HSXLEN.

If HSXLEN is changed from 32 to a wider width, and if field VSXL is not restricted to a single value, it gets the value corresponding to the widest supported width not wider than the new HSXLEN.

The hstatus fields VTSR, VTW, and VTVM are defined analogously to the mstatus fields TSR, TW, and TVM, but affect execution only in VS-mode, and cause virtual-instruction exceptions instead of illegal-instruction exceptions. When VTSR=1, an attempt in VS-mode to execute SRET raises a virtual-instruction exception. When VTW=1 (and assuming mstatus.TW=0), an attempt in VS-mode to execute WFI raises a virtual-instruction exception if the WFI does not complete within an implementation-specific, bounded time limit. An implementation may have WFI always raise a virtual-instruction exception in VS-mode when VTW=1 (and mstatus.TW=0), even if there are pending globally-disabled interrupts when the instruction is executed. When VTVM=1, an attempt in VS-mode to execute SFENCE.VMA or SINVAL.VMA or to access CSR satp raises a virtual-instruction exception.

The VGEIN (Virtual Guest External Interrupt Number) field selects a guest external interrupt source for VS-level external interrupts. VGEIN is a WLRL field that must be able to hold values between zero and the maximum guest external interrupt number (known as GEILEN), inclusive. When VGEIN=0, no guest external interrupt source is selected for VS-level external interrupts. GEILEN may be zero, in which case VGEIN may be read-only zero. Guest external interrupts are explained in Hypervisor Guest External Interrupt Registers (hgeip and hgeie), and the use of VGEIN is covered further in Hypervisor Interrupt Registers (hvip, hip, and hie).

Field HU (Hypervisor in U-mode) controls whether the virtual-machine load/store instructions, HLV, HLVX, and HSV, can be used also in U-mode. When HU=1, these instructions can be executed in U-mode the same as in HS-mode. When HU=0, all hypervisor instructions cause an illegal-instruction exception in U-mode.

The SPV bit (Supervisor Previous Virtualization mode) is written by the implementation whenever a trap is taken into HS-mode. Just as the SPP bit in sstatus is set to the (nominal) privilege mode at the time of the trap, the SPV bit in hstatus is set to the value of the virtualization mode V at the time of the trap. When an SRET instruction is executed when V=0, V is set to SPV.

When V=1 and a trap is taken into HS-mode, bit SPVP (Supervisor Previous Virtual Privilege) is set to the nominal privilege mode at the time of the trap, the same as sstatus.SPP. But if V=0 before a trap, SPVP is left unchanged on trap entry. SPVP controls the effective privilege of explicit memory accesses made by the virtual-machine load/store instructions, HLV, HLVX, and HSV.

Field GVA (Guest Virtual Address) is written by the implementation whenever a trap is taken into HS-mode. For any trap (breakpoint, address misaligned, access fault, page fault, or guest-page fault) that writes a guest virtual address to stval, GVA is set to 1. For any other trap into HS-mode, GVA is set to 0.

The VSBE bit is a WARL field that controls the endianness of explicit memory accesses made from VS-mode. If VSBE=0, explicit load and store memory accesses made from VS-mode are little-endian, and if VSBE=1, they are big-endian. VSBE also controls the endianness of all implicit accesses to VS-level memory management data structures, such as page tables. An implementation may make VSBE a read-only field that always specifies the same endianness as HS-mode.

Register hedeleg is a 64-bit read/write register, formatted as shown in Hypervisor exception delegation register (hedeleg).. Register hideleg is an HSXLEN-bit read/write register, formatted as shown in Hypervisor exception delegation register (hideleg).. By default, all traps at any privilege level are handled in M-mode, though M-mode usually uses the medeleg and mideleg CSRs to delegate some traps to HS-mode. The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest; their layout is the same as medeleg and mideleg.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hedelegreg.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hidelegreg.edn[]

A synchronous trap that has been delegated to HS-mode (using medeleg) is further delegated to VS-mode if V=1 before the trap and the corresponding hedeleg bit is set. Each bit of hedeleg shall be either writable or read-only zero. Many bits of hedeleg are required specifically to be writable or zero, as enumerated in Bits of hedeleg that must be writable or must be read-only zero.. Bit 0, corresponding to instruction address misaligned exceptions, must be writable if IALIGN=32.

When XLEN=32, hedelegh is a 32-bit read/write register that aliases bits 63:32 of hedeleg. Register hedelegh does not exist when XLEN=64.

An interrupt that has been delegated to HS-mode (using mideleg) is further delegated to VS-mode if the corresponding hideleg bit is set. Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.

When a virtual supervisor external interrupt (code 10) is delegated to VS-mode, it is automatically translated by the machine into a supervisor external interrupt (code 9) for VS-mode, including the value written to vscause on an interrupt trap. Likewise, a virtual supervisor timer interrupt (6) is translated into a supervisor timer interrupt (5) for VS-mode, and a virtual supervisor software interrupt (2) is translated into a supervisor software interrupt (1) for VS-mode. Similar translations may or may not be done for platform interrupt causes (codes 16 and above).

Register hvip is an HSXLEN-bit read/write register that a hypervisor can write to indicate virtual interrupts intended for VS-mode. Bits of hvip that are not writable are read-only zeros.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hvipreg.edn[]

The standard portion (bits 15:0) of hvip is formatted as shown in Standard portion (bits 15:0) of hvip.. Bits VSEIP, VSTIP, and VSSIP of hvip are writable. Setting VSEIP=1 in hvip asserts a VS-level external interrupt; setting VSTIP asserts a VS-level timer interrupt; and setting VSSIP asserts a VS-level software interrupt.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hvipreg-standard.edn[]

Registers hip and hie are HSXLEN-bit read/write registers that supplement HS-level’s sip and sie respectively. The hip register indicates pending VS-level and hypervisor-specific interrupts, while hie contains enable bits for the same interrupts.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hipreg.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hiereg.edn[]

For each writable bit in sie, the corresponding bit shall be read-only zero in both hip and hie. Hence, the nonzero bits in sie and hie are always mutually exclusive, and likewise for sip and hip.

An interrupt i will trap to HS-mode whenever all of the following are true: (a) either the current operating mode is HS-mode and the SIE bit in the sstatus register is set, or the current operating mode has less privilege than HS-mode; (b) bit i is set in both sip and sie, or in both hip and hie; and (c) bit i is not set in hideleg.

If bit i of sie is read-only zero, the same bit in register hip may be writable or may be read-only. When bit i in hip is writable, a pending interrupt i can be cleared by writing 0 to this bit. If interrupt i can become pending in hip but bit i in hip is read-only, then either the interrupt can be cleared by clearing bit i of hvip, or the implementation must provide some other mechanism for clearing the pending interrupt (which may involve a call to the execution environment).

A bit in hie shall be writable if the corresponding interrupt can ever become pending in hip. Bits of hie that are not writable shall be read-only zero.

The standard portions (bits 15:0) of registers hip and hie are formatted as shown in Standard portion (bits 15:0) of hip. and Standard portion (bits 15:0) of hie. respectively.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hipreg-standard.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hiereg-standard.edn[]

Bits hip.SGEIP and hie.SGEIE are the interrupt-pending and interrupt-enable bits for guest external interrupts at supervisor level (HS-level). SGEIP is read-only in hip, and is 1 if and only if the bitwise logical-AND of CSRs hgeip and hgeie is nonzero in any bit. (See Hypervisor Guest External Interrupt Registers (hgeip and hgeie).)

Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable bits for VS-level external interrupts. VSEIP is read-only in hip, and is the logical-OR of these interrupt sources:

Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the logical-OR of hvip.VSTIP and any other platform-specific timer interrupt signal directed to VS-level.

Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and interrupt-enable bits for VS-level software interrupts. VSSIP in hip is an alias (writable) of the same bit in hvip.

Multiple simultaneous interrupts destined for HS-mode are handled in the following decreasing priority order: SEI, SSI, STI, SGEI, VSEI, VSSI, VSTI.

The hgeip register is an HSXLEN-bit read-only register, formatted as shown in Hypervisor guest external interrupt-pending register (hgeip)., that indicates pending guest external interrupts for this hart. The hgeie register is an HSXLEN-bit read/write register, formatted as shown in Hypervisor guest external interrupt-enable register (hgeie)., that contains enable bits for the guest external interrupts at this hart. Guest external interrupt number i corresponds with bit i in both hgeip and hgeie.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hgeipreg.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hgeiereg.edn[]

Guest external interrupts represent interrupts directed to individual virtual machines at VS-level. If a RISC-V platform supports placing a physical device under the direct control of a guest OS with minimal hypervisor intervention (known as pass-through or direct assignment between a virtual machine and the physical device), then, in such circumstance, interrupts from the device are intended for a specific virtual machine. Each bit of hgeip summarizes all pending interrupts directed to one virtual hart, as collected and reported by an interrupt controller. To distinguish specific pending interrupts from multiple devices, software must query the interrupt controller.

The number of bits implemented in hgeip and hgeie for guest external interrupts is UNSPECIFIED and may be zero. This number is known as GEILEN. The least-significant bits are implemented first, apart from bit 0. Hence, if GEILEN is nonzero, bits GEILEN:1 shall be writable in hgeie, and all other bit positions shall be read-only zeros in both hgeip and hgeie.

Register hgeie selects the subset of guest external interrupts that cause a supervisor-level (HS-level) guest external interrupt. The enable bits in hgeie do not affect the VS-level external interrupt signal selected from hgeip by hstatus.VGEIN.

The henvcfg CSR is a 64-bit read/write register, formatted as shown in Hypervisor environment configuration register (henvcfg)., that controls certain characteristics of the execution environment when virtualization mode V=1.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/henvcfg.edn[]

If bit FIOM (Fence of I/O implies Memory) is set to one in henvcfg, FENCE instructions executed when V=1 are modified so the requirement to order accesses to device I/O implies also the requirement to order main memory accesses. Modified interpretation of FENCE predecessor and successor sets when FIOM=1 and virtualization mode V=1. details the modified interpretation of FENCE instruction bits PI, PO, SI, and SO when FIOM=1 and V=1.

Similarly, when FIOM=1 and V=1, if an atomic instruction that accesses a region ordered as device I/O has its aq and/or rl bit set, then that instruction is ordered as though it accesses both device I/O and memory.

The PBMTE bit controls whether the Svpbmt extension is available for use in VS-stage address translation. When PBMTE=1, Svpbmt is available for VS-stage address translation. When PBMTE=0, the implementation behaves as though Svpbmt were not implemented for VS-stage address translation. If Svpbmt is not implemented, PBMTE is read-only zero.

If the Svadu extension is implemented, the ADUE bit controls whether hardware updating of PTE A/D bits is enabled for VS-stage address translation. When ADUE=1, hardware updating of PTE A/D bits is enabled during VS-stage address translation, and the implementation behaves as though the Svade extension were not implemented for VS-mode address translation. When ADUE=0, the implementation behaves as though Svade were implemented for VS-stage address translation. If Svadu is not implemented, ADUE is read-only zero.

The definition of the STCE field will be furnished by the forthcoming Sstc extension. Its allocation within henvcfg may change prior to the

The definition of the CBZE field will be furnished by the forthcoming Zicboz extension. Its allocation within henvcfg may change prior to the ratification of that extension.

The definitions of the CBCFE and CBIE fields will be furnished by the forthcoming Zicbom extension. Their allocations within henvcfg may change prior to the ratification of that extension.

The definition of the PMM field will be furnished by the forthcoming Ssnpm extension. Its allocation within henvcfg may change prior to the ratification of that extension.

When XLEN=32, henvcfgh is a 32-bit read/write register that aliases bits 63:32 of henvcfg. Register henvcfgh does not exist when XLEN=64.

The counter-enable register hcounteren is a 32-bit register that controls the availability of the hardware performance monitoring counters to the guest virtual machine.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hcounterenreg.edn[]

When the CY, TM, IR, or HPM_n_ bit in the hcounteren register is clear, attempts to read the cycle, time, instret, or hpmcounter n register while V=1 will cause a virtual-instruction exception if the same bit in mcounteren is 1. When one of these bits is set, access to the corresponding register is permitted when V=1, unless prevented for some other reason. In VU-mode, a counter is not readable unless the applicable bits are set in both hcounteren and scounteren.

hcounteren must be implemented. However, any of the bits may be read-only zero, indicating reads to the corresponding counter will cause an exception when V=1. Hence, they are effectively WARL fields.

The htimedelta CSR is a 64-bit read/write register that contains the delta between the value of the time CSR and the value returned in VS-mode or VU-mode. That is, reading the time CSR in VS or VU mode returns the sum of the contents of htimedelta and the actual value of time.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/htimedelta.edn[]

When XLEN=32, htimedeltah is a 32-bit read/write register that aliases bits 63:32 of htimedelta. Register htimedeltah does not exist when XLEN=64.

The htval register is an HSXLEN-bit read/write register formatted as shown in Hypervisor trap value register (htval).. When a trap is taken into HS-mode, htval is written with additional exception-specific information, alongside stval, to assist software in handling the trap.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/htvalreg.edn[]

When a guest-page-fault trap is taken into HS-mode, htval is written with either zero or the guest physical address that faulted, shifted right by 2 bits. For other traps, htval is set to zero, but a future standard or extension may redefine htval’s setting for other traps.

A guest-page fault may arise due to an implicit memory access during first-stage (VS-stage) address translation, in which case a guest physical address written to htval is that of the implicit memory access that faulted—for example, the address of a VS-level page table entry that could not be read. (The guest physical address corresponding to the original virtual address is unknown when VS-stage translation fails to complete.) Additional information is provided in CSR htinst to disambiguate such situations.

Otherwise, for misaligned loads and stores that cause guest-page faults, a nonzero guest physical address in htval corresponds to the faulting portion of the access as indicated by the virtual address in stval. For instruction guest-page faults on systems with variable-length instructions, a nonzero htval corresponds to the faulting portion of the instruction as indicated by the virtual address in stval.

htval is a WARL register that must be able to hold zero and may be capable of holding only an arbitrary subset of other 2-bit-shifted guest physical addresses, if any.

The htinst register is an HSXLEN-bit read/write register formatted as shown in Hypervisor trap instruction register (htinst).. When a trap is taken into HS-mode, htinst is written with a value that, if nonzero, provides information about the instruction that trapped, to assist software in handling the trap. The values that may be written to htinst on a trap are documented in Transformed Instruction or Pseudoinstruction for mtinst or htinst.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/htinstreg.edn[]

htinst is a WARL register that need only be able to hold the values that the implementation may automatically write to it on a trap.

The hgatp register is an HSXLEN-bit read/write register, formatted as shown in Hypervisor guest address translation and protection register hgatp when HSXLEN=32. for HSXLEN=32 and Hypervisor guest address translation and protection register hgatp when HSXLEN=64 for MODE values Bare, Sv39x4, and Sv57x4. for HSXLEN=64, which controls G-stage address translation and protection, the second stage of two-stage translation for guest virtual addresses (see Two-Stage Address Translation). Similar to CSR satp, this register holds the physical page number (PPN) of the guest-physical root page table; a virtual machine identifier (VMID), which facilitates address-translation fences on a per-virtual-machine basis; and the MODE field, which selects the address-translation scheme for guest physical addresses. When mstatus.TVM=1, attempts to read or write hgatp while executing in HS-mode will raise an illegal-instruction exception.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/rv32hgatp.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/rv64hgatp.edn[]

Encoding of hgatp MODE field. shows the encodings of the MODE field when HSXLEN=32 and HSXLEN=64. When MODE=Bare, guest physical addresses are equal to supervisor physical addresses, and there is no further memory protection for a guest virtual machine beyond the physical memory protection scheme described in [pmp]. In this case, the remaining fields in hgatp must be set to zeros.

When HSXLEN=32, the only other valid setting for MODE is Sv32x4, which is a modification of the usual Sv32 paged virtual-memory scheme, extended to support 34-bit guest physical addresses. When HSXLEN=64, modes Sv39x4, Sv48x4, and Sv57x4 are defined as modifications of the Sv39, Sv48, and Sv57 paged virtual-memory schemes. All of these paged virtual-memory schemes are described in Guest Physical Address Translation.

The remaining MODE settings when HSXLEN=64 are reserved for future use and may define different interpretations of the other fields in hgatp.

Implementations are not required to support all defined MODE settings when HSXLEN=64.

A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated.

As explained in Guest Physical Address Translation, for the paged virtual-memory schemes (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB and must be aligned to a 16-KiB boundary. In these modes, the lowest two bits of the physical page number (PPN) in hgatp always read as zeros. An implementation that supports only the defined paged virtual-memory schemes and/or Bare may make PPN[1:0] read-only zero.

The number of VMID bits is UNSPECIFIED and may be zero. The number of implemented VMID bits, termed VMIDLEN, may be determined by writing one to every bit position in the VMID field, then reading back the value in hgatp to see which bit positions in the VMID field hold a one. The least-significant bits of VMID are implemented first: that is, if VMIDLEN > 0, VMID[VMIDLEN-1:0] is writable. The maximal value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4, Sv48x4, and Sv57x4.

The hgatp register is considered active for the purposes of the address-translation algorithm unless the effective privilege mode is U and hstatus.HU=0.

Note that writing hgatp does not imply any ordering constraints between page-table updates and subsequent G-stage address translations. If the new virtual machine’s guest physical page tables have been modified, or if a VMID is reused, it may be necessary to execute an HFENCE.GVMA instruction (see Hypervisor Memory-Management Fence Instructions) before or after writing hgatp.

The vsstatus register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register sstatus, formatted as shown in Virtual supervisor status register (vstatus) when VSXLEN=32. when VSXLEN=32 and Virtual supervisor status register (vsstatus) when VSXLEN=64. when VSXLEN=64. When V=1, vsstatus substitutes for the usual sstatus, so instructions that normally read or modify sstatus actually access vsstatus instead.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsstatusreg-rv32.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsstatusreg.edn[]

The UXL field controls the effective XLEN for VU-mode, which may differ from the XLEN for VS-mode (VSXLEN). When VSXLEN=32, the UXL field does not exist, and VU-mode XLEN=32. When VSXLEN=64, UXL is a WARL field that is encoded the same as the MXL field of misa, shown in [misabase]. In particular, an implementation may make UXL be a read-only copy of field VSXL of hstatus, forcing VU-mode XLEN=VSXLEN.

If VSXLEN is changed from 32 to a wider width, and if field UXL is not restricted to a single value, it gets the value corresponding to the widest supported width not wider than the new VSXLEN.

When V=1, both vsstatus.FS and the HS-level sstatus.FS are in effect. Attempts to execute a floating-point instruction when either field is 0 (Off) raise an illegal-instruction exception. Modifying the floating-point state when V=1 causes both fields to be set to 3 (Dirty).

Similarly, when V=1, both vsstatus.VS and the HS-level sstatus.VS are in effect. Attempts to execute a vector instruction when either field is 0 (Off) raise an illegal-instruction exception. Modifying the vector state when V=1 causes both fields to be set to 3 (Dirty).

Read-only fields SD and XS summarize the extension context status as it is visible to VS-mode only. For example, the value of the HS-level sstatus.FS does not affect vsstatus.SD.

An implementation may make field UBE be a read-only copy of hstatus.VSBE.

When V=0, vsstatus does not directly affect the behavior of the machine, unless a virtual-machine load/store (HLV, HLVX, or HSV) or the MPRV feature in the mstatus register is used to execute a load or store as though V=1.

The vsip and vsie registers are VSXLEN-bit read/write registers that are VS-mode’s versions of supervisor CSRs sip and sie, formatted as shown in Virtual supervisor interrupt-pending register (vsip). and Virtual supervisor interrupt-enable register (vsie). respectively. When V=1, vsip and vsie substitute for the usual sip and sie, so instructions that normally read or modify sip/sie actually access vsip/vsie instead. However, interrupts directed to HS-level continue to be indicated in the HS-level sip register, not in vsip, when V=1.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsipreg.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsiereg.edn[]

The standard portions (bits 15:0) of registers vsip and vsie are formatted as shown in Standard portion (bits 15:0) of vsip. and Standard portion (bits 15:0) of vsie. respectively.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsipreg-standard.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsiereg-standard.edn[]

When bit 13 of hideleg is zero, vsip.LCOFIP and vsie.LCOFIE are read-only zeros. Else, vsip.LCOFIP and vsie.LCOFIE are aliases of sip.LCOFIP and sie.LCOFIE.

When bit 10 of hideleg is zero, vsip.SEIP and vsie.SEIE are read-only zeros. Else, vsip.SEIP and vsie.SEIE are aliases of hip.VSEIP and hie.VSEIE.

When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE.

When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and hie.VSSIE.

The vstvec register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register stvec, formatted as shown in Virtual supervisor trap vector base address register vstvec.. When V=1, vstvec substitutes for the usual stvec, so instructions that normally read or modify stvec actually access vstvec instead. When V=0, vstvec does not directly affect the behavior of the machine.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vstvecreg.edn[]

The vsscratch register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register sscratch, formatted as shown in Virtual supervisor scratch register vsscratch.. When V=1, vsscratch substitutes for the usual sscratch, so instructions that normally read or modify sscratch actually access vsscratch instead. The contents of vsscratch never directly affect the behavior of the machine.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsscratchreg.edn[]

The vsepc register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register sepc, formatted as shown in Virtual supervisor exception program counter (vsepc).. When V=1, vsepc substitutes for the usual sepc, so instructions that normally read or modify sepc actually access vsepc instead. When V=0, vsepc does not directly affect the behavior of the machine.

vsepc is a WARL register that must be able to hold the same set of values that sepc can hold.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vsepcreg.edn[]

The vscause register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register scause, formatted as shown in Virtual supervisor cause register (vscause).. When V=1, vscause substitutes for the usual scause, so instructions that normally read or modify scause actually access vscause instead. When V=0, vscause does not directly affect the behavior of the machine.

vscause is a WLRL register that must be able to hold the same set of values that scause can hold.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vscausereg.edn[]

The vstval register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register stval, formatted as shown in Virtual supervisor trap value register (vstval).. When V=1, vstval substitutes for the usual stval, so instructions that normally read or modify stval actually access vstval instead. When V=0, vstval does not directly affect the behavior of the machine.

vstval is a WARL register that must be able to hold the same set of values that stval can hold.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/vstvalreg.edn[]

The vsatp register is a VSXLEN-bit read/write register that is VS-mode’s version of supervisor register satp, formatted as shown in Virtual supervisor address translation and protection register vsatp when VSXLEN=32. for VSXLEN=32 and Virtual supervisor address translation and protection register vsatp when VSXLEN=64. for VSXLEN=64. When V=1, vsatp substitutes for the usual satp, so instructions that normally read or modify satp actually access vsatp instead. vsatp controls VS-stage address translation, the first stage of two-stage translation for guest virtual addresses (see Two-Stage Address Translation).

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/rv32vsatpreg.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/rv64vsatpreg.edn[]

The vsatp register is considered active for the purposes of the address-translation algorithm unless the effective privilege mode is U and hstatus.HU=0. However, even when vsatp is active, VS-stage page-table entries’ A bits must not be set as a result of speculative execution, unless the effective privilege mode is VS or VU.

When V=0, a write to vsatp with an unsupported MODE value is either ignored as it is for satp, or the fields of vsatp are treated as WARL in the normal way. However, when V=1, a write to satp with an unsupported MODE value is ignored and no write to vsatp is effected.

When V=0, vsatp does not directly affect the behavior of the machine, unless a virtual-machine load/store (HLV, HLVX, or HSV) or the MPRV feature in the mstatus register is used to execute a load or store as though V=1.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/hypv-virt-load-and-store.edn[]

The hypervisor virtual-machine load and store instructions are valid only in M-mode or HS-mode, or in U-mode when hstatus.HU=1. Each instruction performs an explicit memory access as though V=1; i.e., with the address translation and protection, and the endianness, that apply to memory accesses in either VS-mode or VU-mode. Field SPVP of hstatus controls the privilege level of the access. The explicit memory access is done as though in VU-mode when SPVP=0, and as though in VS-mode when SPVP=1. As usual when V=1, two-stage address translation is applied, and the HS-level sstatus.SUM is ignored. HS-level sstatus.MXR makes execute-only pages readable for both stages of address translation (VS-stage and G-stage), whereas vsstatus.MXR affects only the first translation stage (VS-stage).

For every RV32I or RV64I load instruction, LB, LBU, LH, LHU, LW, LWU, and LD, there is a corresponding virtual-machine load instruction: HLV.B, HLV.BU, HLV.H, HLV.HU, HLV.W, HLV.WU, and HLV.D. For every RV32I or RV64I store instruction, SB, SH, SW, and SD, there is a corresponding virtual-machine store instruction: HSV.B, HSV.H, HSV.W, and HSV.D. Instructions HLV.WU, HLV.D, and HSV.D are not valid for RV32, of course.

Instructions HLVX.HU and HLVX.WU are the same as HLV.HU and HLV.WU, except that execute permission takes the place of read permission during address translation. That is, the memory being read must be executable in both stages of address translation, but read permission is not required. For the supervisor physical address that results from address translation, the supervisor physical memory attributes must grant both execute and read permissions. (The supervisor physical memory attributes are the machine’s physical memory attributes as modified by physical memory protection, [pmp], for supervisor level.)

HLVX.WU is valid for RV32, even though LWU and HLV.WU are not. (For RV32, HLVX.WU can be considered a variant of HLV.W, as sign extension is irrelevant for 32-bit values.)

Attempts to execute a virtual-machine load/store instruction (HLV, HLVX, or HSV) when V=1 cause a virtual-instruction exception. Attempts to execute one of these same instructions from U-mode when hstatus.HU=0 cause an illegal-instruction exception.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/hypv-mm-fence.edn[]

The hypervisor memory-management fence instructions, HFENCE.VVMA and HFENCE.GVMA, perform a function similar to SFENCE.VMA ([sfence.vma]), except applying to the VS-level memory-management data structures controlled by CSR vsatp (HFENCE.VVMA) or the guest-physical memory-management data structures controlled by CSR hgatp (HFENCE.GVMA). Instruction SFENCE.VMA applies only to the memory-management data structures controlled by the current satp (either the HS-level satp when V=0 or vsatp when V=1).

HFENCE.VVMA is valid only in M-mode or HS-mode. Its effect is much the same as temporarily entering VS-mode and executing SFENCE.VMA. Executing an HFENCE.VVMA guarantees that any previous stores already visible to the current hart are ordered before all implicit reads by that hart done for VS-stage address translation for instructions that

Implicit reads need not be ordered when hgatp.VMID is different than at the time HFENCE.VVMA executed. If operand rs1≠x0, it specifies a single guest virtual address, and if operand rs2≠x0, it specifies a single guest address-space identifier (ASID).

When rs2≠x0, bits XLEN-1:ASIDMAX of the value held in rs2 are reserved for future standard use. Until their use is defined by a standard extension, they should be zeroed by software and ignored by current implementations. Furthermore, if ASIDLEN < ASIDMAX, the implementation shall ignore bits ASIDMAX-1:ASIDLEN of the value held in rs2.

Neither mstatus.TVM nor hstatus.VTVM causes HFENCE.VVMA to trap.

HFENCE.GVMA is valid only in HS-mode when mstatus.TVM=0, or in M-mode (irrespective of mstatus.TVM). Executing an HFENCE.GVMA instruction guarantees that any previous stores already visible to the current hart are ordered before all implicit reads by that hart done for G-stage address translation for instructions that follow the HFENCE.GVMA. If operand rs1≠x0, it specifies a single guest physical address, shifted right by 2 bits, and if operand rs2≠x0, it specifies a single virtual machine identifier (VMID).

When rs2≠x0, bits XLEN-1:VMIDMAX of the value held in rs2 are reserved for future standard use. Until their use is defined by a standard extension, they should be zeroed by software and ignored by current implementations. Furthermore, if VMIDLEN < VMIDMAX, the implementation shall ignore bits VMIDMAX-1:VMIDLEN of the value held in rs2.

If hgatp.MODE is changed for a given VMID, an HFENCE.GVMA with rs1=x0 (and rs2 set to either x0 or the VMID) must be executed to order subsequent guest translations with the MODE change—even if the old MODE or new MODE is Bare.

Attempts to execute HFENCE.VVMA or HFENCE.GVMA when V=1 cause a virtual-instruction exception, while attempts to do the same in U-mode cause an illegal-instruction exception. Attempting to execute HFENCE.GVMA in HS-mode when mstatus.TVM=1 also causes an illegal-instruction exception.

The hypervisor extension adds two fields, MPV and GVA, to the machine-level mstatus or mstatush CSR, and modifies the behavior of several existing mstatus fields. Machine status register (mstatus) fpr RV64 when the hypervisor extension is implemented. shows the modified mstatus register when the hypervisor extension is implemented and MXLEN=64. When MXLEN=32, the hypervisor extension adds MPV and GVA not to mstatus but to mstatush. Additional machine status register (mstatush) for RV32 when the hypervisor extension is implemented. The format of mstatus is unchanged for RV32. shows the mstatush register when the hypervisor extension is implemented and MXLEN=32.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hypv-mstatus.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hypv-mstatush.edn[]

The MPV bit (Machine Previous Virtualization Mode) is written by the implementation whenever a trap is taken into M-mode. Just as the MPP field is set to the (nominal) privilege mode at the time of the trap, the MPV bit is set to the value of the virtualization mode V at the time of the trap. When an MRET instruction is executed, the virtualization mode V is set to MPV, unless MPP=3, in which case V remains 0.

Field GVA (Guest Virtual Address) is written by the implementation whenever a trap is taken into M-mode. For any trap (breakpoint, address misaligned, access fault, page fault, or guest-page fault) that writes a guest virtual address to mtval, GVA is set to 1. For any other trap into M-mode, GVA is set to 0.

The TSR and TVM fields of mstatus affect execution only in HS-mode, not in VS-mode. The TW field affects execution in all modes except M-mode.

Setting TVM=1 prevents HS-mode from accessing hgatp or executing HFENCE.GVMA or HINVAL.GVMA, but has no effect on accesses to vsatp or instructions HFENCE.VVMA or HINVAL.VVMA.

The hypervisor extension changes the behavior of the Modify Privilege field, MPRV, of mstatus. When MPRV=0, translation and protection behave as normal. When MPRV=1, explicit memory accesses are translated and protected, and endianness is applied, as though the current virtualization mode were set to MPV and the current nominal privilege mode were set to MPP. Effect of MPRV on the translation and protection of explicit memory accesses. enumerates the cases.

MPRV does not affect the virtual-machine load/store instructions, HLV, HLVX, and HSV. The explicit loads and stores of these instructions always act as though V=1 and the nominal privilege mode were hstatus.SPVP, overriding MPRV.

The mstatus register is a superset of the HS-level sstatus register but is not a superset of vsstatus.

When the hypervisor extension is implemented, bits 10, 6, and 2 of mideleg (corresponding to the standard VS-level interrupts) are each read-only one. Furthermore, if any guest external interrupts are implemented (GEILEN is nonzero), bit 12 of mideleg (corresponding to supervisor-level guest external interrupts) is also read-only one. VS-level interrupts and guest external interrupts are always delegated past M-mode to HS-mode.

For bits of mideleg that are zero, the corresponding bits in hideleg, hip, and hie are read-only zeros.

The hypervisor extension gives registers mip and mie additional active bits for the hypervisor-added interrupts. Standard portion (bits 15:0) of mip. and Standard portion (bits 15:0) of mie. show the standard portions (bits 15:0) of registers mip and mie when the hypervisor extension is implemented.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hypv-mipreg-standard.edn[]

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/hypv-miereg-standard.edn[]

Bits SGEIP, VSEIP, VSTIP, and VSSIP in mip are aliases for the same bits in hypervisor CSR hip, while SGEIE, VSEIE, VSTIE, and VSSIE in mie are aliases for the same bits in hie.

The mtval2 register is an MXLEN-bit read/write register formatted as shown in Machine second trap value register (mtval2).. When a trap is taken into M-mode, mtval2 is written with additional exception-specific information, alongside mtval, to assist software in handling the trap.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/mtval2reg.edn[]

When a guest-page-fault trap is taken into M-mode, mtval2 is written with either zero or the guest physical address that faulted, shifted right by 2 bits. For other traps, mtval2 is set to zero, but a future standard or extension may redefine mtval2’s setting for other traps.

If a guest-page fault is due to an implicit memory access during first-stage (VS-stage) address translation, a guest physical address written to mtval2 is that of the implicit memory access that faulted. Additional information is provided in CSR mtinst to disambiguate such situations.

Otherwise, for misaligned loads and stores that cause guest-page faults, a nonzero guest physical address in mtval2 corresponds to the faulting portion of the access as indicated by the virtual address in mtval. For instruction guest-page faults on systems with variable-length instructions, a nonzero mtval2 corresponds to the faulting portion of the instruction as indicated by the virtual address in mtval.

mtval2 is a WARL register that must be able to hold zero and may be capable of holding only an arbitrary subset of other 2-bit-shifted guest physical addresses, if any.

The mtinst register is an MXLEN-bit read/write register formatted as shown in Machine trap instruction register (mtinst).. When a trap is taken into M-mode, mtinst is written with a value that, if nonzero, provides information about the instruction that trapped, to assist software in handling the trap. The values that may be written to mtinst on a trap are documented in Transformed Instruction or Pseudoinstruction for mtinst or htinst.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/mtinstreg.edn[]

mtinst is a WARL register that need only be able to hold the values that the implementation may automatically write to it on a trap.

The mapping of guest physical addresses to supervisor physical addresses is controlled by CSR hgatp (Hypervisor Guest Address Translation and Protection Register (hgatp)).

When the address translation scheme selected by the MODE field of hgatp is Bare, guest physical addresses are equal to supervisor physical addresses without modification, and no memory protection applies in the trivial translation of guest physical addresses to supervisor physical addresses.

When hgatp.MODE specifies a translation scheme of Sv32x4, Sv39x4, Sv48x4, or Sv57x4, G-stage address translation is a variation on the usual page-based virtual address translation scheme of Sv32, Sv39, Sv48, or Sv57, respectively. In each case, the size of the incoming address is widened by 2 bits (to 34, 41, 50, or 59 bits). To accommodate the 2 extra bits, the root page table (only) is expanded by a factor of four to be 16 KiB instead of the usual 4 KiB. Matching its larger size, the root page table also must be aligned to a 16 KiB boundary instead of the usual 4 KiB page boundary. Except as noted, all other aspects of Sv32, Sv39, Sv48, or Sv57 are adopted unchanged for G-stage translation. Non-root page tables and all page table entries (PTEs) have the same formats as documented in [sv32], [sv39], [sv48], and [sv57].

For Sv32x4, an incoming guest physical address is partitioned into a virtual page number (VPN) and page offset as shown in Sv32x4 virtual address (guest physical address).. This partitioning is identical to that for an Sv32 virtual address as depicted in [sv32va], except with 2 more bits at the high end in VPN[1]. (Note that the fields of a partitioned guest physical address also correspond one-for-one with the structure that Sv32 assigns to a physical address, depicted in [sv32va].)

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/sv32x4va.edn[]

For Sv39x4, an incoming guest physical address is partitioned as shown in Sv39x4 virtual address (guest physical address).. This partitioning is identical to that for an Sv39 virtual address as depicted in [sv39va], except with 2 more bits at the high end in VPN[2]. Address bits 63:41 must all be zeros, or else a guest-page-fault exception occurs.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/sv39x4va.edn[]

For Sv48x4, an incoming guest physical address is partitioned as shown in Sv48x4 virtual address (guest physical address).. This partitioning is identical to that for an Sv48 virtual address as depicted in [sv48va], except with 2 more bits at the high end in VPN[3]. Address bits 63:50 must all be zeros, or else a guest-page-fault exception occurs.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/sv48x4va.edn[]

For Sv57x4, an incoming guest physical address is partitioned as shown in Sv57x4 virtual address (guest physical address).. This partitioning is identical to that for an Sv57 virtual address as depicted in [sv57va], except with 2 more bits at the high end in VPN[4]. Address bits 63:59 must all be zeros, or else a guest-page-fault exception occurs.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/bytefield/sv57x4va.edn[]

The conversion of an Sv32x4, Sv39x4, Sv48x4, or Sv57x4 guest physical address is accomplished with the same algorithm used for Sv32, Sv39, Sv48, or Sv57, as presented in [sv32algorithm], except that:

For G-stage address translation, all memory accesses (including those made to access data structures for VS-stage address translation) are considered to be user-level accesses, as though executed in U-mode. Access type permissions—readable, writable, or executable—are checked during G-stage translation the same as for VS-stage translation. For a memory access made to support VS-stage address translation (such as to read/write a VS-level page table), permissions and the need to set A and/or D bits at the G-stage level are checked as though for an implicit load or store, not for the original access type. However, any exception is always reported for the original access type (instruction, load, or store/AMO).

The G bit in all G-stage PTEs is reserved for future standard use. Until its use is defined by a standard extension, it should be cleared by software for forward compatibility, and must be ignored by hardware.

Guest-page-fault traps may be delegated from M-mode to HS-mode under the control of CSR medeleg, but cannot be delegated to other privilege modes. On a guest-page fault, CSR mtval or stval is written with the faulting guest virtual address as usual, and mtval2 or htval is written either with zero or with the faulting guest physical address, shifted right by 2 bits. CSR mtinst or htinst may also be written with information about the faulting instruction or other reason for the access, as explained in Transformed Instruction or Pseudoinstruction for mtinst or htinst.

When an instruction fetch or a misaligned memory access straddles a page boundary, two different address translations are involved. When a guest-page fault occurs in such a circumstance, the faulting virtual address written to mtval/stval is the same as would be required for a regular page fault. Thus, the faulting virtual address may be a page-boundary address that is higher than the instruction’s original virtual address, if the byte at that page boundary is among the accessed bytes.

When a guest-page fault is not due to an implicit memory access for VS-stage address translation, a nonzero guest physical address written to mtval2/htval shall correspond to the exact virtual address written to mtval/stval.

The behavior of the SFENCE.VMA instruction is affected by the current virtualization mode V. When V=0, the virtual-address argument is an HS-level virtual address, and the ASID argument is an HS-level ASID. The instruction orders stores only to HS-level address-translation structures with subsequent HS-level address translations.

When V=1, the virtual-address argument to SFENCE.VMA is a guest virtual address within the current virtual machine, and the ASID argument is a VS-level ASID within the current virtual machine. The current virtual machine is identified by the VMID field of CSR hgatp, and the effective ASID can be considered to be the combination of this VMID with the VS-level ASID. The SFENCE.VMA instruction orders stores only to the VS-level address-translation structures with subsequent VS-stage address translations for the same virtual machine, i.e., only when hgatp.VMID is the same as when the SFENCE.VMA executed.

Hypervisor instructions HFENCE.VVMA and HFENCE.GVMA provide additional memory-management fences to complement SFENCE.VMA. These instructions are described in Hypervisor Memory-Management Fence Instructions.

[pmp-vmem] discusses the intersection between physical memory protection (PMP) and page-based address translation. It is noted there that, when PMP settings are modified in a manner that affects either the physical memory that holds page tables or the physical memory to which page tables point, M-mode software must synchronize the PMP settings with the virtual memory system. For HS-level address translation, this is accomplished by executing in M-mode an SFENCE.VMA instruction with rs1=x0 and rs2=x0, after the PMP CSRs are written. Synchronization with G-stage and VS-stage data structures is also needed. Executing an HFENCE.GVMA instruction with rs1=x0 and rs2=x0 suffices to flush all G-stage or VS-stage address-translation cache entries that have cached PMP settings corresponding to the final translated supervisor physical address. An HFENCE.VVMA instruction is not required.

Similarly, if the setting of the PBMTE bit in menvcfg is changed, an HFENCE.GVMA instruction with rs1=x0 and rs2=x0 suffices to synchronize with respect to the altered interpretation of G-stage and VS-stage PTEs' PBMT fields.

By contrast, if the PBMTE bit in henvcfg is changed, executing an HFENCE.VVMA with rs1=x0 and rs2=x0 suffices to synchronize with respect to the altered interpretation of VS-stage PTEs' PBMT fields for the currently active VMID.

The hypervisor extension augments the trap cause encoding. Machine and supervisor cause register (mcause and scause) values when the hypervisor extension is implemented. lists the possible M-mode and HS-mode trap cause codes when the hypervisor extension is implemented. Codes are added for VS-level interrupts (interrupts 2, 6, 10), for supervisor-level guest external interrupts (interrupt 12), for virtual-instruction exceptions (exception 22), and for guest-page faults (exceptions 20, 21, 23). Furthermore, environment calls from VS-mode are assigned cause 10, whereas those from HS-mode or S-mode use cause 9 as usual.

HS-mode and VS-mode ECALLs use different cause values so they can be delegated separately.

When V=1, a virtual-instruction exception (code 22) is normally raised instead of an illegal-instruction exception if the attempted instruction is HS-qualified but is prevented from executing when V=1 either due to insufficient privilege or because the instruction is expressly disabled by a supervisor or hypervisor CSR such as scounteren or hcounteren. An instruction is HS-qualified if it would be valid to execute in HS-mode (for some values of the instruction’s register operands), assuming fields TSR and TVM of CSR mstatus are both zero.

A special rule applies for CSR instructions that access 32-bit high-half CSRs such as cycleh and htimedeltah. When V=1 and XLEN=32, an invalid attempt to access a high-half CSR raises a virtual-instruction exception instead of an illegal-instruction exception if the same CSR instruction for the corresponding low-half CSR (e.g.cycle or htimedelta) is HS-qualified.

Specifically, a virtual-instruction exception is raised for the following cases:

Other extensions to the RISC-V Privileged Architecture may add to the set of circumstances that cause a virtual-instruction exception when V=1.

On a virtual-instruction trap, mtval or stval is written the same as for an illegal-instruction trap.

If an instruction may raise multiple synchronous exceptions, the decreasing priority order of Synchronous exception priority when the hypervisor extension is implemented. indicates which exception is taken and reported in mcause or scause.

When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode. When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless delegated by medeleg or mideleg, in which case it goes to HS-mode, unless further delegated by hedeleg or hideleg, in which case it goes to VS-mode.

When a trap is taken into M-mode, virtualization mode V gets set to 0, and fields MPV and MPP in mstatus (or mstatush) are set according to Value of mstatus/mstatush fields MPV and MPP after a trap into M-mode. Upon trap return, MPV is ignored when MPP=3.. A trap into M-mode also writes fields GVA, MPIE, and MIE in mstatus/mstatush and writes CSRs mepc, mcause, mtval, mtval2, and mtinst.

When a trap is taken into HS-mode, virtualization mode V is set to 0, and hstatus.SPV and sstatus.SPP are set according to Value of hstatus field SPV and sstatus field SPP after a trap into HS-mode.. If V was 1 before the trap, field SPVP in hstatus is set the same as sstatus.SPP; otherwise, SPVP is left unchanged. A trap into HS-mode also writes field GVA in hstatus, fields SPIE and SIE in sstatus, and CSRs sepc, scause, stval, htval, and htinst.

When a trap is taken into VS-mode, vsstatus.SPP is set according to Value of vsstatus field SPP after a trap into VS-mode.. Register hstatus and the HS-level sstatus are not modified, and the virtualization mode V remains 1. A trap into VS-mode also writes fields SPIE and SIE in vsstatus and writes CSRs vsepc, vscause, and vstval.

On any trap into M-mode or HS-mode, one of these values is written automatically into the appropriate trap instruction CSR, mtinst or htinst:

Except when a pseudoinstruction value is required (described later), the value written to mtinst or htinst may always be zero, indicating that the hardware is providing no information in the register for this particular trap.

On an interrupt, the value written to the trap instruction register is always zero. On a synchronous exception, if a nonzero value is written, one of the following shall be true about the value:

These three cases exclude a large number of other possible values, such as all those having bits 1:0 equal to binary 10. A future standard or extension may define additional cases, thus allowing values that are currently excluded. Software may safely treat an unrecognized value in a trap instruction register the same as zero.

Values that may be automatically written to the trap instruction register (mtinst or htinst) on an exception trap. shows the values that may be automatically written to the trap instruction register for each standard exception cause. For exceptions that prevent the fetching of an instruction, only zero or a pseudoinstruction value may be written. A custom value may be automatically written only if the instruction that traps is non-standard. A future standard or extension may permit other values to be written, chosen from the set of allowed values established earlier.

As enumerated in the table, a synchronous exception may write to the trap instruction register a standard transformation of the trapping instruction only for exceptions that arise from explicit memory accesses (from loads, stores, and AMO instructions). Accordingly, standard transformations are currently defined only for these memory-access instructions. If a synchronous trap occurs for a standard instruction for which no transformation has been defined, the trap instruction register shall be written with zero (or, under certain circumstances, with a special pseudoinstruction value).

For a standard load instruction that is not a compressed instruction and is one of LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, FLQ, or FLH, the transformed instruction has the format shown in Transformed noncompressed load instruction (LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, FLQ, or FLH). Fields funct3, rd, and opcode are the same as the trapping load instruction..

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/transformedloadinst.edn[]

For a standard store instruction that is not a compressed instruction and is one of SB, SH, SW, SD, FSW, FSD, FSQ, or FSH, the transformed instruction has the format shown in Transformed noncompressed store instruction (SB, SH, SW, SD, FSW, FSD, FSQ, or FSH). Fields rs2, funct3, and opcode are the same as the trapping store instruction..

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/transformedstoreinst.edn[]

For a standard atomic instruction (load-reserved, store-conditional, or AMO instruction), the transformed instruction has the format shown in Transformed atomic instruction (load-reserved, store-conditional, or AMO instruc-tion). All fields are the same as the trapping instruction except bits 19:15, Addr. Offset..

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/transformedatomicinst.edn[]

For a standard virtual-machine load/store instruction (HLV, HLVX, or HSV), the transformed instruction has the format shown in Transformed virtual-machine load/store instruction (HLV, HLVX, HSV). All fields are the same as the trapping instruction except bits 19:15, Addr. Offset.

Unresolved include directive in modules/chapters/pages/hypervisor.adoc - include::images/wavedrom/transformedvmaccessinst.edn[]

In all the transformed instructions above, the Addr. Offset field that replaces the instruction’s rs1 field in bits 19:15 is the positive difference between the faulting virtual address (written to mtval or stval) and the original virtual address. This difference can be nonzero only for a misaligned memory access. Note also that, for basic loads and stores, the transformations replace the instruction’s immediate offset fields with zero.

For a standard compressed instruction (16-bit size), the transformed instruction is found as follows:

Bits 1:0 of a transformed standard instruction will be binary 01 if the trapping instruction is compressed and 11 if not.

For guest-page faults, the trap instruction register is written with a special pseudoinstruction value if: (a) the fault is caused by an implicit memory access for VS-stage address translation, and (b) a nonzero value (the faulting guest physical address) is written to mtval2 or htval. If both conditions are met, the value written to mtinst or htinst must be taken from Special pseudoinstruction values for guest-page faults. The RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64.; zero is not allowed.

The defined pseudoinstruction values are designed to correspond closely with the encodings of basic loads and stores, as illustrated by Standard instructions corresponding to the special psudoinstructions of [pseudoinsts]..

A write pseudoinstruction (0x00002020 or 0x00003020) is used for the case that the machine is attempting automatically to update bits A and/or D in VS-level page tables. All other implicit memory accesses for VS-stage address translation will be reads. If a machine never automatically updates bits A or D in VS-level page tables (leaving this to software), the write case will never arise. The fact that such a page table update must actually be atomic, not just a simple write, is ignored for the pseudoinstruction.

The MRET instruction is used to return from a trap taken into M-mode. MRET first determines what the new privilege mode will be according to the values of MPP and MPV in mstatus or mstatush, as encoded in Value of mstatus/mstatush fields MPV and MPP after a trap into M-mode. Upon trap return, MPV is ignored when MPP=3.. MRET then in mstatus/mstatush sets MPV=0, MPP=0, MIE=MPIE, and MPIE=1. Lastly, MRET sets the privilege mode as previously determined, and sets pc=mepc.

The SRET instruction is used to return from a trap taken into HS-mode or VS-mode. Its behavior depends on the current virtualization mode.

When executed in M-mode or HS-mode (i.e., V=0), SRET first determines what the new privilege mode will be according to the values in hstatus.SPV and sstatus.SPP, as encoded in Value of hstatus field SPV and sstatus field SPP after a trap into HS-mode.. SRET then sets hstatus.SPV=0, and in sstatus sets SPP=0, SIE=SPIE, and SPIE=1. Lastly, SRET sets the privilege mode as previously determined, and sets pc=sepc.

When executed in VS-mode (i.e., V=1), SRET sets the privilege mode according to Value of vsstatus field SPP after a trap into VS-mode., in vsstatus sets SPP=0, SIE=SPIE, and SPIE=1, and lastly sets pc=vsepc.