Update hypervisor spec to v0.6

h/t @jhauser-us, as usual

2 files changed, 423 insertions, 248 deletions

diff --git a/src/hypervisor.tex b/src/hypervisor.tex
index 5cdf98f..7b6189f 100644
--- a/src/hypervisor.tex
+++ b/src/hypervisor.tex
@@ -1,7 +1,7 @@
-\chapter{Hypervisor Extension, Version 0.5}
+\chapter{Hypervisor Extension, Version 0.6}
 \label{hypervisor}
 
-{\bf Warning! This draft specification is likely to change before being
+{\bf Warning! This draft specification may change before being
 accepted as standard by the RISC-V Foundation.}
 
 This chapter describes the RISC-V hypervisor extension, which virtualizes the
@@ -32,10 +32,6 @@ Implementations that include the hypervisor extension are encouraged
 not to hardwire {\tt misa}[7], so that the extension may be disabled.
 
 \begin{commentary}
-This draft is based on earlier proposals by John Hauser and Paolo Bonzini.
-\end{commentary}
-
-\begin{commentary}
 The baseline privileged architecture is designed to simplify the use of classic
 virtualization techniques, where a guest OS is run at user-level, as
 the few privileged instructions can be easily detected and trapped.
@@ -87,7 +83,7 @@ An OS or hypervisor running in HS-mode uses the supervisor CSRs to interact with
 interrupt, and address-translation subsystems.
 Additional CSRs are provided to HS-mode, but not to VS-mode, to manage
 two-stage address translation and to control the behavior of a VS-mode guest:
-{\tt hstatus}, {\tt hedeleg}, {\tt hideleg}, {\tt hip}, {\tt hie},
+{\tt hstatus}, {\tt hedeleg}, {\tt hideleg}, {\tt hvip}, {\tt hip}, {\tt hie},
 {\tt hgeip}, {\tt hgeie},
 {\tt hcounteren}, {\tt htimedelta}, {\tt htimedeltah}, {\tt htval},
 {\tt htinst}, and {\tt hgatp}.
@@ -104,7 +100,7 @@ Instructions that normally read or modify a supervisor CSR shall instead
 access the corresponding VS CSR.
 In VS-mode, an attempt to read or write a VS CSR directly by its own
 separate CSR address causes an illegal instruction exception.
-The VS CSRs can be directly accessed only from M-mode or HS-mode.
+The VS CSRs can be accessed as themselves only from M-mode or HS-mode.
 
 While V=1, the normal HS-level supervisor CSRs that are replaced by
 VS CSRs retain their values but do
@@ -148,7 +144,8 @@ for tracking and controlling the exception behavior of a VS-mode guest.
 {\footnotesize
 \begin{center}
 \setlength{\tabcolsep}{4pt}
-\begin{tabular}{TcccWSc}
+\scalebox{0.95}{
+\begin{tabular}{YcccWYccWcccccF}
 \\
 \instbitrange{31}{23} &
 \instbit{22} &
@@ -156,42 +153,30 @@ for tracking and controlling the exception behavior of a VS-mode guest.
 \instbit{20} &
 \instbitrange{19}{18} &
 \instbitrange{17}{12} &
- \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{VTSR} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{VTVM} &
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{VGEIN[5:0]} &
- \\
-\hline
-9 & 1 & 1 & 1 & 2 & 6 & \\
-\end{tabular}
-\begin{tabular}{cWcccccYc}
-\\
-&
 \instbitrange{11}{10} &
 \instbit{9} &
 \instbit{8} &
 \instbit{7} &
 \instbit{6} &
 \instbit{5} &
-\instbitrange{4}{1} &
-\instbit{0} \\
+\instbitrange{4}{0} \\
 \hline
- &
 \multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{SP2V} &
-\multicolumn{1}{c|}{SP2P} &
-\multicolumn{1}{c|}{SPV} &
+\multicolumn{1}{c|}{VTSR} &
 \multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{VSBE} &
+\multicolumn{1}{c|}{VTVM} &
+\multicolumn{1}{c|}{\wpri} &
+\multicolumn{1}{c|}{VGEIN[5:0]} &
 \multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPRV} \\
+\multicolumn{1}{c|}{HU} &
+\multicolumn{1}{c|}{SPVP} &
+\multicolumn{1}{c|}{SPV} &
+\multicolumn{1}{c|}{GVA} &
+\multicolumn{1}{c|}{VSBE} &
+\multicolumn{1}{c|}{\wpri} \\
 \hline
- & 2 & 1 & 1 & 1 & 1 & 1 & 4 & 1 \\
-\end{tabular}
+9 & 1 & 1 & 1 & 2 & 6 & 2 & 1 & 1 & 1 & 1 & 1 & 5 \\
+\end{tabular}}
 \end{center}
 }
 \vspace{-0.1in}
@@ -223,7 +208,7 @@ for tracking and controlling the exception behavior of a VS-mode guest.
 \hline
 HSXLEN-34 & 2 & 9 & 1 & 1 & 1 & \\
 \end{tabular}
-\begin{tabular}{cWRWcccccFc}
+\begin{tabular}{cWRWcccccY}
 \\
 &
 \instbitrange{19}{18} &
@@ -234,22 +219,20 @@ HSXLEN-34 & 2 & 9 & 1 & 1 & 1 & \\
 \instbit{7} &
 \instbit{6} &
 \instbit{5} &
-\instbitrange{4}{1} &
-\instbit{0} \\
+\instbitrange{4}{0} \\
 \hline
  &
 \multicolumn{1}{|c|}{\wpri} &
 \multicolumn{1}{c|}{VGEIN[5:0]} &
 \multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SP2V} &
-\multicolumn{1}{c|}{SP2P} &
+\multicolumn{1}{c|}{HU} &
+\multicolumn{1}{c|}{SPVP} &
 \multicolumn{1}{c|}{SPV} &
-\multicolumn{1}{c|}{\wpri} &
+\multicolumn{1}{c|}{GVA} &
 \multicolumn{1}{c|}{VSBE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPRV} \\
+\multicolumn{1}{c|}{\wpri} \\
 \hline
- & 2 & 6 & 2 & 1 & 1 & 1 & 1 & 1 & 4 & 1 \\
+ & 2 & 6 & 2 & 1 & 1 & 1 & 1 & 1 & 5 \\
 \end{tabular}
 \end{center}
 }
@@ -264,7 +247,8 @@ 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 {\tt misa}, shown in Table~\ref{misabase} on
 page~\pageref{misabase}.
-In particular, the implementation may hardwire VSXL so that VSXLEN=HSXLEN.
+In particular, the implementation may make VSXL a read-only field forcing
+VSXLEN=HSXLEN.
 
 If HSXLEN is changed from 32 to a wider width, and if field VSXL is not
 hardwired to a forced value, it gets the value corresponding to the
@@ -286,17 +270,53 @@ Guest external interrupts are explained in
 Section~\ref{sec:hgeinterruptregs}, and the use of VGEIN is covered
 further in Section~\ref{sec:hinterruptregs}.
 
-The SPV bit (Supervisor Previous Virtualization Mode) is written by the implementation
+Field HU (Hypervisor User 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 trap
+in U-mode.
+
+\begin{commentary}
+The HU bit allows a portion of a hypervisor to be run in U-mode for
+greater protection against software bugs, while still retaining access to
+a virtual machine's memory.
+\end{commentary}
+
+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 {\tt sstatus} is set to the privilege
 mode at the time of the trap, the SPV bit in {\tt 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 a trap is taken into HS-mode, bits SP2V and SP2P are set to the values
-that SPV and the HS-level SPP had before the trap.
-When an SRET instruction is executed when V=0, the reverse assignments occur:
-after SPV and {\tt sstatus}.SPP have supplied the new virtualization and
-privilege modes, they are written with SP2V and SP2P, respectively.
+When V=1 and a trap is taken into HS-mode, bit SPVP (Supervisor Previous
+Virtual Privilege) is set to the privilege mode at the time of the trap,
+the same as {\tt 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.
+
+\begin{commentary}
+Without SPVP, if instructions HLV, HLVX, and HSV looked instead to
+{\tt sstatus}.SPP for the effective privilege of their memory accesses,
+then, even with HU=1, U-mode could not access virtual machine memory at
+VS-level, because to enter U-mode using SRET always leaves SPP=0.
+Unlike SPP, field SPVP is untouched by transitions back-and-forth between
+HS-mode and U-mode.
+\end{commentary}
+
+Field GVA (Guest Virtual Address) is written by the implementation
+whenever a trap is taken into HS-mode.
+For any trap (access fault, page fault, or guest-page fault) that writes
+a guest virtual address to {\tt stval}, GVA is set to~1.
+For any other trap into HS-mode, GVA is set to~0.
+
+\begin{commentary}
+For memory faults, GVA is redundant with field SPV (the two bits are set
+the same) except when the explicit memory access of an HLV, HLVX, or HSV
+instruction causes a fault.
+In that case, SPV=0 but GVA=1.
+\end{commentary}
 
 The VSBE bit is a \warl\ field that controls the endianness of explicit
 memory accesses made from VS-mode.
@@ -304,37 +324,8 @@ 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 hardwire VSBE to specify always the same endianness
-as for HS-mode.
-
-The SPRV bit modifies the privilege of explicit memory accesses made in
-HS-mode.
-When SPRV=0, translation and protection behave as normal.
-When SPRV=1, explicit memory accesses in HS-mode are translated and
-protected, and endianness is applied, as though the current
-virtualization mode were set to {\tt hstatus}.SPV and the current
-privilege mode were set to the HS-level SPP.
-Table~\ref{h-sprv} enumerates the cases.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c||p{4.7in}|}
-  \hline
-   SPRV & SPV & SPP & Effect \\ \hline \hline
-   0    & --  & --  & Normal access; current privilege and virtualization modes apply. \\ \hline
-   1    & 0   & 0   & U-level access with HS-level translation and protection only. \\ \hline
-   1    & 0   & 1   & HS-level access with HS-level translation and protection only. \\ \hline
-   1    & 1   & 0   & VU-level access with two-stage translation and protection. The HS-level MXR bit makes any executable page readable.  {\tt vsstatus}.MXR makes readable those pages marked executable at the VS translation stage, but only if readable at the guest-physical translation stage. \\ \hline
-   1    & 1   & 1   & VS-level access with two-stage translation and protection. The HS-level MXR bit makes any executable page readable.  {\tt vsstatus}.MXR makes readable those pages marked executable at the VS translation stage, but only if readable at the guest-physical translation stage.  {\tt vsstatus}.SUM applies instead of the HS-level SUM bit. \\ \hline
- \end{tabular}
-\end{center}
-\caption{Effect of SPRV on the translation and protection of explicit
-memory accesses in HS-mode.}
-\label{h-sprv}
-\end{table*}
-
-An MRET or SRET instruction that changes the operating mode to U-mode,
-VS-mode, or VU-mode also sets SPRV=0.
+An implementation may make VSBE a read-only field that always specifies
+the same endianness as HS-mode.
 
 \subsection{Hypervisor Trap Delegation Registers ({\tt hedeleg} and {\tt hideleg})}
 
@@ -444,15 +435,74 @@ software interrupt (2) is translated into a supervisor software interrupt
 Similar translations may or may not be done for platform or custom
 interrupt causes (codes 16 and above).
 
-\subsection{Hypervisor Interrupt Registers ({\tt hip} and {\tt hie})}
+\subsection{Hypervisor Interrupt Registers ({\tt hvip}, {\tt hip}, and {\tt hie})}
 \label{sec:hinterruptregs}
 
+Register {\tt hvip} is an HSXLEN-bit read/write register that a
+hypervisor can write to indicate virtual interrupts intended for VS-mode.
+The bit positions writable in {\tt hideleg} shall also be writable in
+{\tt hvip}, and the other bits of {\tt hvip} shall be hardwired to zeros.
+
+\begin{figure}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}J}
+\instbitrange{HSXLEN-1}{0} \\
+\hline
+\multicolumn{1}{|c|}{Virtual Interrupts (\warl)} \\
+\hline
+HSXLEN \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Hypervisor virtual-interrupt-pending register ({\tt hvip}).}
+\label{hvipreg}
+\end{figure}
+
+The standard portion (bits 15:0) of {\tt hvip} is formatted as shown in
+Figure~\ref{hvipreg-standard}.
+Setting VSEIP=1 in {\tt hvip} asserts a VS-level external interrupt;
+setting VSTIP asserts a VS-level timer interrupt; and setting VSSIP
+asserts a VS-level software interrupt.
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\setlength{\tabcolsep}{4pt}
+\begin{tabular}{RcFcFcW}
+\instbitrange{15}{11} &
+\instbit{10} &
+\instbitrange{9}{7} &
+\instbit{6} &
+\instbitrange{5}{3} &
+\instbit{2} &
+\instbitrange{1}{0} \\
+\hline
+\multicolumn{1}{|c|}{0} &
+\multicolumn{1}{c|}{VSEIP} &
+\multicolumn{1}{c|}{0} &
+\multicolumn{1}{c|}{VSTIP} &
+\multicolumn{1}{c|}{0} &
+\multicolumn{1}{c|}{VSSIP} &
+\multicolumn{1}{c|}{0} \\
+\hline
+5 & 1 & 3 & 1 & 3 & 1 & 2 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Standard portion (bits 15:0) of {\tt hvip}.}
+\label{hvipreg-standard}
+\end{figure*}
+
 Registers {\tt hip} and {\tt hie} are HSXLEN-bit read/write registers
 that supplement HS-level's {\tt sip} and {\tt sie} respectively.
 The {\tt hip} register indicates pending VS-level and hypervisor-specific
 interrupts, while {\tt hie} contains enable bits for the same interrupts.
-Like {\tt sip} and {\tt sie}, interrupt cause number \textit{i}
-corresponds with bit~\textit{i} in both {\tt hip} and {\tt hie}.
+As with {\tt sip} and {\tt sie}, an interrupt \textit{i} will be taken in
+HS-mode if bit~\textit{i} is set in both {\tt hip} and {\tt hie}, and if
+supervisor-level interrupts are globally enabled.
 
 \begin{figure}[h!]
 {\footnotesize
@@ -505,7 +555,9 @@ register {\tt hip} may be writable or may be read-only.
 When bit~\textit{i} in {\tt hip} is writable, a pending interrupt
 \textit{i} can be cleared by writing 0 to this bit.
 If interrupt \textit{i} can become pending in {\tt hip} but
-bit~\textit{i} in {\tt hip} is read-only, the implementation must provide
+bit~\textit{i} in {\tt hip} is read-only, then either
+the interrupt can be cleared by clearing bit~\textit{i}
+of {\tt hvip}, or the implementation must provide
 some other mechanism for clearing the pending interrupt (which may
 involve a call to the execution environment).
 
@@ -594,45 +646,27 @@ logical-AND of CSRs {\tt hgeip} and {\tt hgeie} is nonzero in any bit.
 
 Bits {\tt hip}.VSEIP and {\tt hie}.VSEIE are the interrupt-pending and
 interrupt-enable bits for VS-level external interrupts.
-VSEIP is writable in {\tt hip}, and may be written by a hypervisor to
-indicate to VS-mode that an external interrupt is pending.
-Additionally, VS-level external interrupts may come from other sources,
-such as a platform-level interrupt controller.
-VS-level external interrupts are made pending based on the logical-OR of:
+VSEIP is read-only in {\tt hip}, and is the logical-OR of these interrupt
+sources:
 \begin{tightlist}
 \item
-the software-writable VSEIP bit;
+bit VSEIP of {\tt hvip};
 \item
 the bit of {\tt hgeip} selected by {\tt hstatus}.VGEIN; and
 \item
 any other platform-specific external interrupt signal directed to
 VS-level.
 \end{tightlist}
-When {\tt hip} is read with a CSR instruction, the value of the VSEIP bit
-returned in the {\tt rd} destination register is the logical-OR of all
-the sources listed above.
-However, the value used in the read-modify-write sequence of a CSRRS or
-CSRRC instruction contains only the software-writable VSEIP bit, ignoring
-other interrupt sources.
-
-\begin{commentary}
-The VSEIP field behavior is designed to allow a hypervisor to mimic
-external interrupts cleanly for a guest virtual machine, without losing
-any real external interrupts that may be directed to VS-level.
-The behavior of the CSR instructions is slightly modified from regular
-CSR accesses as a result.
-This modified CSR behavior for VSEIP is the same as given to
-{\tt mip}.SEIP for like reason.
-\end{commentary}
 
 Bits {\tt hip}.VSTIP and {\tt hie}.VSTIE are the interrupt-pending and
 interrupt-enable bits for VS-level timer interrupts.
-VSTIP is writable in {\tt hip}, and may be written by a hypervisor to
-deliver timer interrupts to VS-mode.
+VSTIP is read-only in {\tt hip}, and is the logical-OR of
+{\tt hvip}.VSTIP and any other platform-specific timer interrupt signal
+directed to VS-level.
 
 Bits {\tt hip}.VSSIP and {\tt hie}.VSSIE are the interrupt-pending and
 interrupt-enable bits for VS-level software interrupts.
-VSSIP is writable in {\tt hip}.
+VSSIP in {\tt hip} is an alias (writable) of the same bit in {\tt hvip}.
 
 Multiple simultaneous interrupts destined for HS-mode are handled in the
 following decreasing priority order:  SEI, SSI, STI, SGEI, VSEI, VSSI, VSTI.
@@ -881,19 +915,38 @@ shifted right by 2~bits.
 For other traps, {\tt htval} is set to zero, but a future standard or
 extension may redefine {\tt htval}'s setting for other traps.
 
-For misaligned loads and stores that cause guest-page faults, {\tt htval}
-will contain zero or the guest physical address of the portion of the
-access that caused the fault.
+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 {\tt 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 {\tt htinst} to disambiguate
+such situations.
+
+Otherwise, for misaligned loads and stores that cause guest-page faults,
+a nonzero guest physical address in {\tt htval} corresponds to the
+faulting portion of the access as indicated by the virtual address in
+{\tt stval}.
 For instruction guest-page faults on systems with variable-length
-instructions, {\tt htval} will contain zero or the guest physical address
-of the portion of the instruction that caused the fault.
+instructions, a nonzero {\tt htval} corresponds to the faulting portion
+of the instruction as indicated by the virtual address in {\tt stval}.
 
 \begin{commentary}
-The least-significant two bits of a faulting guest physical address are
-not available in {\tt htval}.
-If needed, these bits are ordinarily the same as the least-significant
+A guest physical address written to {\tt htval} is shifted right by
+2~bits to accommodate addresses wider than the current XLEN.
+For RV32, the hypervisor extension permits guest physical addresses as
+wide as 34 bits, and {\tt htval} reports bits 33:2 of the address.
+This shift-by-2 encoding of guest physical addresses matches the encoding
+of physical addresses in PMP address registers (Section~\ref{sec:pmp})
+and in page table entries (Sections \ref{sec:sv32}, \ref{sec:sv39},
+and~\ref{sec:sv48}).
+
+If the least-significant two bits of a faulting guest physical address
+are needed, these bits are ordinarily the same as the least-significant
 two bits of the faulting virtual address in {\tt stval}.
-For faults due to implicit memory accesses for VS-level address
+For faults due to implicit memory accesses for VS-stage address
 translation, the least-significant two bits are instead zeros.
 These cases can be distinguished using the value provided in register
 {\tt htinst}.
@@ -944,7 +997,9 @@ values that the implementation may automatically write to it on a trap.
 
 The {\tt hgatp} register is an HSXLEN-bit read/write register, formatted as
 shown in Figure~\ref{rv32hgatp} for HSXLEN=32 and Figure~\ref{rv64hgatp} for
-HSXLEN=64, which controls guest physical address translation and protection.
+HSXLEN=64, which controls G-stage address translation and protection, the
+second stage of two-stage translation for guest virtual addresses (see
+Section~\ref{sec:two-stage-translation}).
 Similar to CSR {\tt 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;
@@ -1077,7 +1132,7 @@ The maximal value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4
 and Sv48x4.
 
 Note that writing {\tt hgatp} does not imply any ordering constraints between
-page-table updates and subsequent guest physical address translations.
+page-table updates and subsequent G-stage address translations.
 If the new virtual machine's guest physical page tables have been modified, it
 may be necessary to execute an HFENCE.GVMA instruction
 (see Section~\ref{sec:hfence.vma}) before or after writing {\tt hgatp}.
@@ -1086,7 +1141,7 @@ may be necessary to execute an HFENCE.GVMA instruction
 
 The {\tt vsstatus} register is a VSXLEN-bit read/write register that is
 VS-mode's version of supervisor register {\tt sstatus}, formatted as
-shown in Figure~\ref{vsstatusreg} when VSXLEN=32 and
+shown in Figure~\ref{vsstatusreg-rv32} when VSXLEN=32 and
 Figure~\ref{vsstatusreg} when VSXLEN=64.
 When V=1, {\tt vsstatus} substitutes for the usual {\tt sstatus}, so
 instructions that normally read or modify {\tt sstatus} actually access
@@ -1239,12 +1294,13 @@ is visible to VS-mode only.
 For example, the value of the HS-level {\tt sstatus}.FS does not affect
 {\tt vsstatus}.SD.
 
-An implementation may hardwire field UBE to be always the same as
+An implementation may make field UBE a read-only alias of
 {\tt hstatus}.VSBE.
 
 When V=0, {\tt vsstatus} does not directly affect the behavior of the machine,
-unless the MPRV feature in the {\tt mstatus} register or the SPRV feature
-in the {\tt hstatus} register is used to execute a load or store
+unless a virtual-machine load/store (HLV, HLVX, or HSV)
+or the MPRV feature in the {\tt mstatus}
+register is used to execute a load or store
 {\em as though} V=1.
 
 \subsection{Virtual Supervisor Interrupt Registers ({\tt vsip} and {\tt vsie})}
@@ -1360,18 +1416,18 @@ are formatted as shown in Figures \ref{vsipreg-standard} and
 
 When bit 10 of {\tt hideleg} is zero, {\tt vsip}.SEIP and {\tt vsie}.SEIE
 are read-only zeros.
-Else, {\tt vsip}.SEIP is a read-only alias of {\tt hip}.VSEIP, and
-{\tt vsie}.SEIE is an alias of {\tt hie}.VSEIE.
+Else, {\tt vsip}.SEIP and {\tt vsie}.SEIE are aliases of {\tt hip}.VSEIP
+and {\tt hie}.VSEIE.
 
 When bit 6 of {\tt hideleg} is zero, {\tt vsip}.STIP and {\tt vsie}.STIE
 are read-only zeros.
-Else, {\tt vsip}.STIP is a read-only alias of {\tt hip}.VSTIP, and
-{\tt vsie}.STIE is an alias of {\tt hie}.VSTIE.
+Else, {\tt vsip}.STIP and {\tt vsie}.STIE are aliases of {\tt hip}.VSTIP
+and {\tt hie}.VSTIE.
 
 When bit 2 of {\tt hideleg} is zero, {\tt vsip}.SSIP and {\tt vsie}.SSIE
 are read-only zeros.
-Else, {\tt vsip}.SSIP and {\tt vsie}.SSIE are aliases (both writable) of
-{\tt hip}.VSSIP and {\tt hie}.VSSIE.
+Else, {\tt vsip}.SSIP and {\tt vsie}.SSIE are aliases of {\tt hip}.VSSIP
+and {\tt hie}.VSSIE.
 
 \subsection{Virtual Supervisor Trap Vector Base Address Register ({\tt vstvec})}
 
@@ -1535,19 +1591,10 @@ for VSXLEN=64.
 When V=1, {\tt vsatp} substitutes for the usual {\tt satp}, so
 instructions that normally read or modify {\tt satp} actually access
 {\tt vsatp} instead.
-{\tt vsatp} controls VS-level address translation, the first stage of
+{\tt vsatp} controls VS-stage address translation, the first stage of
 two-stage translation for guest virtual addresses (see
 Section~\ref{sec:two-stage-translation}).
 
-When V=0, a write to {\tt vsatp} with an unsupported MODE value is not
-ignored as it is for {\tt satp}.
-Instead, the fields of {\tt vsatp} are {\warl} in the normal way.
-
-When V=0, {\tt vsatp} does not directly affect the behavior of the machine,
-unless the MPRV feature in the {\tt mstatus} register or the SPRV feature
-in the {\tt hstatus} register is used to execute a load or store
-{\em as though} V=1.
-
 \begin{figure}[h!]
 {\footnotesize
 \begin{center}
@@ -1591,16 +1638,89 @@ values Bare, Sv39, and Sv48.}
 \label{rv64vsatpreg}
 \end{figure*}
 
+When V=0, a write to {\tt vsatp} with an unsupported MODE value is not
+ignored as it is for {\tt satp}.
+Instead, the fields of {\tt vsatp} are {\warl} in the normal way.
+
+When V=0, {\tt 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 {\tt mstatus}
+register is used to execute a load or store
+{\em as though} V=1.
+
 \section{Hypervisor Instructions}
 
-The hypervisor extension adds two privileged fence instructions.
+The hypervisor extension adds virtual-machine load and store instructions
+and two privileged fence instructions.
+
+\subsection{Hypervisor Virtual-Machine Load and Store Instructions}
+
+\vspace{-0.2in}
+\begin{center}
+\begin{tabular}{@{}O@{}R@{}R@{}F@{}R@{}S}
+\\
+\instbitrange{31}{25} &
+\instbitrange{24}{20} &
+\instbitrange{19}{15} &
+\instbitrange{14}{12} &
+\instbitrange{11}{7} &
+\instbitrange{6}{0} \\
+\hline
+\multicolumn{1}{|c|}{funct7} &
+\multicolumn{1}{c|}{rs2} &
+\multicolumn{1}{c|}{rs1} &
+\multicolumn{1}{c|}{funct3} &
+\multicolumn{1}{c|}{rd} &
+\multicolumn{1}{c|}{opcode} \\
+\hline
+7 & 5 & 5 & 3 & 5 & 7 \\
+HLV.\textit{width} & [U]  & addr & PRIVM & dest & SYSTEM \\
+HLVX.HU/WU         & HLVX & addr & PRIVM & dest & SYSTEM \\
+HSV.\textit{width} & src  & addr & PRIVM & 0    & SYSTEM \\
+\end{tabular}
+\end{center}
+
+The hypervisor virtual-machine load and store instructions are valid only
+in M-mode or HS-mode, or in U-mode when {\tt 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 {\tt 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 {\tt sstatus}.SUM is ignored.
+HS-level {\tt sstatus}.MXR makes execute-only pages readable for
+both stages of address translation (VS-stage and G-stage), whereas
+{\tt 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 \textit{execute} permission takes the place of \textit{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.
+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.)
+
+HLVX cannot override machine-level physical memory protection (PMP),
+so attempting to read memory that PMP designates as execute-only still
+results in an access fault.
 
 \subsection{Hypervisor Memory-Management Fence Instructions}
 \label{sec:hfence.vma}
 
 \vspace{-0.2in}
 \begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}S}
+\begin{tabular}{@{}O@{}R@{}R@{}F@{}R@{}S}
 \\
 \instbitrange{31}{25} &
 \instbitrange{24}{20} &
@@ -1617,24 +1737,23 @@ The hypervisor extension adds two privileged fence instructions.
 \multicolumn{1}{c|}{opcode} \\
 \hline
 7 & 5 & 5 & 3 & 5 & 7 \\
-HFENCE.GVMA & vmid & gaddr & PRIV & 0 & SYSTEM \\
 HFENCE.VVMA & asid & vaddr & PRIV & 0 & SYSTEM \\
+HFENCE.GVMA & vmid & gaddr & PRIV & 0 & SYSTEM \\
 \end{tabular}
 \end{center}
 
-The hypervisor memory-management fence instructions, HFENCE.GVMA and
-HFENCE.VVMA, are valid only in HS-mode when {\tt mstatus}.TVM=0, or in M-mode
-(irrespective of {\tt mstatus}.TVM).
-These instructions perform a function similar to SFENCE.VMA
-(Section~\ref{sec:sfence.vma}), except applying to the guest-physical
-memory-management data structures controlled by CSR {\tt hgatp} (HFENCE.GVMA)
-or the VS-level memory-management data structures controlled by CSR {\tt vsatp}
-(HFENCE.VVMA).
+The hypervisor memory-management fence instructions, HFENCE.VVMA
+and HFENCE.GVMA, perform a function similar to SFENCE.VMA
+(Section~\ref{sec:sfence.vma}), except applying to the VS-level
+memory-management data structures controlled by CSR {\tt vsatp}
+(HFENCE.VVMA) or the guest-physical memory-management data structures
+controlled by CSR {\tt hgatp} (HFENCE.GVMA).
 Instruction SFENCE.VMA applies only to the memory-management data structures
 controlled by the current {\tt satp} (either the HS-level {\tt satp} when
 V=0 or {\tt vsatp} when V=1).
 
-If an HFENCE.VVMA instruction executes without trapping, its effect is much the
+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 subsequent implicit reads by that
@@ -1673,6 +1792,11 @@ virtual machines, or even a global fence for all memory-management data
 structures.
 \end{commentary}
 
+Neither {\tt mstatus}.TVM nor {\tt hstatus}.VTVM causes HFENCE.VVMA to
+trap.
+
+HFENCE.GVMA is valid only in HS-mode when {\tt mstatus}.TVM=0, or in
+M-mode (irrespective of {\tt mstatus}.TVM).
 Executing an HFENCE.GVMA instruction guarantees that any previous stores
 already visible to the current hart are ordered before all subsequent implicit
 reads by that hart of guest-physical memory-management data structures done for instructions
@@ -1682,13 +1806,9 @@ address, shifted right by 2~bits, and if operand {\em rs2}$\neq${\tt x0}, it
 specifies a single virtual machine identifier (VMID).
 
 \begin{commentary}
-For HFENCE.GVMA, a guest physical address specified in {\em rs1} is shifted
+Like for a guest physical address written to {\tt htval} on a
+trap, a guest physical address specified in {\em rs1} is shifted
 right by 2~bits to accommodate addresses wider than the current XLEN.
-For RV32, the hypervisor extension permits guest physical addresses as wide as
-34 bits, and {\em rs1} specifies bits 33:2 of such an address.
-This shift-by-2 encoding of guest physical addresses matches the encoding of
-physical addresses in PMP address registers (Section~\ref{sec:pmp}) and in page
-table entries (Sections \ref{sec:sv32}, \ref{sec:sv39}, and~\ref{sec:sv48}).
 \end{commentary}
 
 When {\em rs2}$\neq${\tt x0}, bits XLEN-1:VMIDMAX of the value held in {\em
@@ -1712,12 +1832,12 @@ adds CSRs {\tt mtval2} and {\tt mtinst}.
 
 \subsection{Machine Status Registers ({\tt mstatus} and {\tt mstatush})}
 
-The hypervisor extension adds one field, MPV, to the
+The hypervisor extension adds two fields, MPV and GVA, to the
 machine-level {\tt mstatus} or {\tt mstatush} CSR, and modifies the
 behavior of several existing {\tt mstatus} fields.
 Figure~\ref{hypervisor-mstatus} shows the modified {\tt mstatus} register
 when the hypervisor extension is implemented and MXLEN=64.
-When MXLEN=32, the hypervisor extension adds MPV not to {\tt mstatus}
+When MXLEN=32, the hypervisor extension adds MPV and GVA not to {\tt mstatus}
 but to {\tt mstatush}, which must exist.
 Figure~\ref{hypervisor-mstatush} shows the {\tt mstatush} register when
 the hypervisor extension is implemented and MXLEN=32.
@@ -1741,7 +1861,7 @@ the hypervisor extension is implemented and MXLEN=32.
 \multicolumn{1}{|c|}{SD} &
 \multicolumn{1}{c|}{\wpri} &
 \multicolumn{1}{c|}{MPV} &
-\multicolumn{1}{c|}{\wpri} &
+\multicolumn{1}{c|}{GVA} &
 \multicolumn{1}{c|}{MBE} &
 \multicolumn{1}{c|}{SBE} &
 \multicolumn{1}{c|}{SXL[1:0]} &
@@ -1830,7 +1950,7 @@ the hypervisor extension is implemented and MXLEN=32.
 \hline
 \multicolumn{1}{|c|}{\wpri} &
 \multicolumn{1}{c|}{MPV} &
-\multicolumn{1}{c|}{\wpri} &
+\multicolumn{1}{c|}{GVA} &
 \multicolumn{1}{c|}{MBE} &
 \multicolumn{1}{c|}{SBE} &
 \multicolumn{1}{c|}{\wpri} \\
@@ -1851,10 +1971,28 @@ mode at the time of the trap, the MPV bit is set to the value of the virtualizat
 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 (access fault, page fault, or guest-page fault) that writes
+a guest virtual address to {\tt mtval}, GVA is set to~1.
+For any other trap into M-mode, GVA is set to~0.
+
 The TSR and TVM fields of {\tt 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 {\tt hgatp} or executing
+HFENCE.GVMA, but has no effect on accesses to {\tt vsatp} or instruction
+HFENCE.VVMA.
+
+The hypervisor extension changes the behavior of the the Modify Privilege
+field, MPRV, of {\tt 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 privilege mode were set to MPP.
+Table~\ref{h-mprv} enumerates the cases.
+
 \begin{table*}[h!]
 \begin{center}
 \begin{tabular}{|c|c|c||p{4.5in}|}
@@ -1869,20 +2007,14 @@ The TW field affects execution in all modes except M-mode.
  \end{tabular}
 \end{center}
 \caption{Effect of MPRV on the translation and protection of explicit
-memory accesses.
-When MPRV=1, MPP$\neq$3, and {\tt hstatus}.SPRV=1, the effective
-privilege is further modified: {\tt hstatus}.SPV applies instead of MPV,
-and the HS-level SPP applies instead of MPP.}
+memory accesses.}
 \label{h-mprv}
 \end{table*}
 
-The hypervisor extension changes the behavior of the the Modify Privilege
-field, MPRV, of {\tt 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 privilege mode were set to MPP.
-Table~\ref{h-mprv} 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 privilege mode were {\tt hstatus}.SPVP, overriding MPRV.
 
 The {\tt mstatus} register is a superset of the HS-level {\tt sstatus}
 register but is not a superset of {\tt vsstatus}.
@@ -1999,12 +2131,6 @@ Bits SGEIP, VSEIP, VSTIP, and VSSIP in {\tt mip} are aliases for the same bits
 in hypervisor CSR {\tt hip}, while SGEIE, VSEIE, VSTIE, and VSSIE in {\tt mie}
 are aliases for the same bits in {\tt hie}.
 
-Instructions CSRRS and CSRRC have the same modified behavior for bit
-VSEIP in {\tt mip} as they do for VSEIP in {\tt hip}, as described in
-Section~\ref{sec:hinterruptregs}.
-There is only one software-writable VSEIP bit, accessible through either
-{\tt mip} or {\tt hip}.
-
 \subsection{Machine Second Trap Value Register ({\tt mtval2})}
 
 The {\tt mtval2} register is an MXLEN-bit read/write register formatted
@@ -2036,12 +2162,20 @@ shifted right by 2~bits.
 For other traps, {\tt mtval2} is set to zero, but a future standard or
 extension may redefine {\tt mtval2}'s setting for other traps.
 
-For misaligned loads and stores that cause guest-page faults,
-{\tt mtval2} will contain zero or the guest physical address of the
-portion of the access that caused the fault.
+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 {\tt mtval2} is that of the implicit memory access that
+faulted.
+Additional information is provided in CSR {\tt mtinst} to disambiguate
+such situations.
+
+Otherwise, for misaligned loads and stores that cause guest-page faults,
+a nonzero guest physical address in {\tt mtval2} corresponds to the
+faulting portion of the access as indicated by the virtual address in
+{\tt mtval}.
 For instruction guest-page faults on systems with variable-length
-instructions, {\tt mtval2} will contain zero or the guest physical
-address of the portion of the instruction that caused the fault.
+instructions, a nonzero {\tt mtval2} corresponds to the faulting portion
+of the instruction as indicated by the virtual address in {\tt mtval}.
 
 {\tt 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
@@ -2080,8 +2214,8 @@ values that the implementation may automatically write to it on a trap.
 \section{Two-Stage Address Translation}
 \label{sec:two-stage-translation}
 
-Whenever the current virtualization mode V is 1 (and assuming
-{\tt mstatus}.MPRV=0), two-stage address translation and protection is in
+Whenever the current virtualization mode V is 1,
+two-stage address translation and protection is in
 effect.
 For any virtual memory access, the original virtual address is
 converted in the first stage
@@ -2091,19 +2225,20 @@ The guest physical address is then converted
 in the second stage by guest physical address
 translation, as controlled by the {\tt hgatp} register, into a supervisor
 physical address.
+The two stages are known also as VS-stage and G-stage translation.
 Although there is no option to disable two-stage address translation when V=1,
 either stage of translation can be effectively disabled by zeroing the
 corresponding {\tt vsatp} or {\tt hgatp} register.
 
 The {\tt vsstatus} field MXR, which makes execute-only pages readable, only
-overrides VS-level page protection.
+overrides VS-stage page protection.
 Setting MXR at VS-level does not override guest-physical page protections.
-Setting MXR at HS-level, however, overrides both VS-level and guest-physical
+Setting MXR at HS-level, however, overrides both VS-stage and G-stage
 execute-only permissions.
 
 When V=1, memory accesses that would normally bypass address translation are
-subject to guest physical address translation alone.
-This includes memory accesses made in support of VS-level address translation,
+subject to G-stage address translation alone.
+This includes memory accesses made in support of VS-stage address translation,
 such as reads and writes of VS-level page tables.
 
 Machine-level physical memory protection applies to supervisor physical
@@ -2121,7 +2256,7 @@ without modification, and no memory protection applies in the trivial
 translation of guest physical addresses to supervisor physical addresses.
 
 When {\tt hgatp}.MODE specifies a translation scheme of Sv32x4, Sv39x4, or
-Sv48x4, guest physical address translation is a variation on the usual
+Sv48x4, G-stage address translation is a variation on the usual
 page-based virtual address translation scheme of Sv32, Sv39, or Sv48,
 respectively.
 In each case, the size of the incoming address is widened by 2~bits (to 34, 41,
@@ -2131,7 +2266,7 @@ 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, or Sv48 are adopted unchanged
-for guest physical address translation.
+for G-stage translation.
 Non-root page tables and all page table entries (PTEs) have the same formats as
 documented in Sections \ref{sec:sv32}, \ref{sec:sv39}, and~\ref{sec:sv48}.
 
@@ -2230,7 +2365,7 @@ exception occurs.
 \end{figure*}
 
 \begin{commentary}
-The page-based guest physical address translation scheme for RV32, Sv32x4, is
+The page-based G-stage address translation scheme for RV32, Sv32x4, is
 defined to support a 34-bit guest physical address so that an RV32 hypervisor
 need not be limited in its ability to virtualize real 32-bit RISC-V machines,
 even those with 33-bit or 34-bit physical addresses.
@@ -2264,23 +2399,23 @@ guest-page-fault exceptions are raised instead of regular page-fault
 exceptions.
 \end{compactitem}
 
-For guest physical address translation, all memory accesses (including those
-made to access data structures for VS-level address translation) are considered
+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 guest physical address translation the same as for VS-level address
+during G-stage translation the same as for VS-stage
 translation.
-For a memory access made to support VS-level address translation (such as to
+For a memory access made to support VS-stage address translation (such as to
 read/write a VS-level page table), permissions are checked as though for a 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).
 
 \begin{commentary}
-Guest physical address translation uses the identical format for PTEs as
+G-stage address translation uses the identical format for PTEs as
 regular address translation, even including the U~bit, due to the
-possibility of sharing some (or all) page tables between guest physical
-address translation and regular HS-level address translation.
+possibility of sharing some (or all) page tables between G-stage
+translation and regular HS-level address translation.
 Regardless of whether this usage will ever become common, we chose not to
 preclude it.
 \end{commentary}
@@ -2306,9 +2441,12 @@ 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.
-A nonzero guest physical address written by the machine to
-{\tt mtval2}/{\tt htval}
-shall always correspond to the exact guest virtual address written to
+
+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
+{\tt mtval2}/{\tt htval} shall correspond
+to the exact virtual address written to
 {\tt mtval}/{\tt stval}.
 
 \subsection{Memory-Management Fences}
@@ -2326,11 +2464,11 @@ The current virtual machine is identified by the VMID field of CSR {\tt 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-level address translations
+address-translation structures with subsequent VS-stage address translations
 for the same virtual machine, i.e., only when {\tt hgatp}.VMID is the same as
 when the SFENCE.VMA executed.
 
-Hypervisor instructions HFENCE.GVMA and HFENCE.VVMA provide additional
+Hypervisor instructions HFENCE.VVMA and HFENCE.GVMA provide additional
 memory-management fences to complement SFENCE.VMA.
 These instructions are described in Section~\ref{sec:hfence.vma}.
 
@@ -2343,7 +2481,8 @@ the virtual memory system.
 For HS-level address translation, this is accomplished by executing in M-mode
 an SFENCE.VMA instruction with {\em rs1}={\tt x0} and {\em rs2}={\tt x0}, after
 the PMP CSRs are written.
-If guest physical address translation is in use, synchronization with its data
+If G-stage address translation is in use and is not Bare,
+synchronization with its data
 structures is also needed.
 When PMP settings are modified in a manner that affects either the physical
 memory that holds guest-physical page tables or the physical memory to which
@@ -2367,6 +2506,15 @@ it in U-mode when S-mode exists.
 
 \subsection{Trap Cause Codes}
 
+The hypervisor extension augments the trap cause encoding.
+Table~\ref{hcauses} 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), 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.
+
 \begin{table*}[p]
 \begin{center}
 \begin{tabular}{|r|r|l|l|}
@@ -2421,14 +2569,6 @@ it in U-mode when S-mode exists.
 \label{hcauses}
 \end{table*}
 
-The hypervisor extension augments the trap cause encoding.
-Table~\ref{hcauses} 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) 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.
-
 \begin{commentary}
 HS-mode and VS-mode ECALLs use different cause values so they can be delegated
 separately.
@@ -2444,9 +2584,11 @@ unless further delegated by {\tt hedeleg} or {\tt 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 in {\tt mstatus} (or {\tt mstatush}) MPV and MPP are set according to
+and fields MPV and MPP in {\tt mstatus}
+(or {\tt mstatush}) are set according to
 Table~\ref{h-mpp}.
-A trap into M-mode also writes CSRs {\tt mepc}, {\tt mcause},
+A trap into M-mode also writes fields GVA, MPIE, and MIE in
+{\tt mstatus}/{\tt mstatush} and writes CSRs {\tt mepc}, {\tt mcause},
 {\tt mtval}, {\tt mtval2}, and {\tt mtinst}.
 
 \begin{table*}[h!]
@@ -2466,11 +2608,14 @@ Upon trap return, MPV is ignored when MPP=3.}
 \label{h-mpp}
 \end{table*}
 
-When a trap is taken into HS-mode, virtualization mode V is first set to~0,
-{\tt hstatus}.SP2V is set to {\tt hstatus}.SPV, {\tt hstatus}.SP2P is set
-to {\tt sstatus}.SPP, and lastly {\tt hstatus}.SPV and {\tt sstatus}.SPP are
+When a trap is taken into HS-mode, virtualization mode V is set to~0,
+and {\tt hstatus}.SPV and {\tt sstatus}.SPP are
 set according to Table~\ref{h-spp}.
-A trap into HS-mode also writes CSRs {\tt sepc}, {\tt scause},
+If V was 1 before the trap, field SPVP in {\tt hstatus} is set the same as
+{\tt sstatus}.SPP;
+otherwise, SPVP is left unchanged.
+A trap into HS-mode also writes field GVA in {\tt hstatus}, fields
+SPIE and SIE in {\tt sstatus}, and CSRs {\tt sepc}, {\tt scause},
 {\tt stval}, {\tt htval}, and {\tt htinst}.
 
 \begin{table*}[h!]
@@ -2492,7 +2637,8 @@ When a trap is taken into VS-mode, {\tt vsstatus}.SPP is set according to
 Table~\ref{h-vspp}.
 Register {\tt hstatus} and the HS-level {\tt sstatus} are not modified,
 and the virtualization mode V remains~1.
-A trap into VS-mode also writes CSRs {\tt vsepc}, {\tt vscause}, and
+A trap into VS-mode also writes fields SPIE and SIE in
+{\tt vsstatus} and writes CSRs {\tt vsepc}, {\tt vscause}, and
 {\tt vstval}.
 
 \begin{table*}[h!]
@@ -2540,7 +2686,7 @@ instruction from memory, and partly by obviating some of the work of
 decoding and executing the instruction.
 The second purpose is to supply, via pseudoinstructions, additional
 information about guest-page-fault exceptions caused by implicit memory
-accesses done for VS-level address translation.
+accesses done for VS-stage address translation.
 
 A \emph{transformation} of the trapping instruction is written instead of
 simply a copy of the original instruction in order to minimize the burden
@@ -2671,6 +2817,8 @@ transformation has been defined, the trap instruction register shall be
 written with zero (or, under certain circumstances, with a special
 pseudoinstruction value).
 
+\FloatBarrier
+
 For a standard load instruction that is not a compressed instruction and
 is one of LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, or FLQ, the
 transformed instruction has the format shown in
@@ -2679,7 +2827,7 @@ Figure~\ref{transformedloadinst}.
 \begin{figure*}[h!]
 {\footnotesize
 \begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}S}
+\begin{tabular}{@{}O@{}R@{}R@{}F@{}R@{}S}
 \\
 \instbitrange{31}{25} &
 \instbitrange{24}{20} &
@@ -2714,7 +2862,7 @@ has the format shown in Figure~\ref{transformedstoreinst}.
 \begin{figure*}[h!]
 {\footnotesize
 \begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}S}
+\begin{tabular}{@{}O@{}R@{}R@{}F@{}R@{}S}
 \\
 \instbitrange{31}{25} &
 \instbitrange{24}{20} &
@@ -2781,12 +2929,45 @@ Addr.\ Offset.}
 \label{transformedatomicinst}
 \end{figure*}
 
-In the transformed instructions above, the Addr.\ Offset field that
+For a standard virtual-machine load/store instruction
+(HLV, HLVX, or HSV), the transformed instruction has the format shown in
+Figure~\ref{transformedvmaccessinst}.
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}O@{}R@{}R@{}F@{}R@{}S}
+\\
+\instbitrange{31}{25} &
+\instbitrange{24}{20} &
+\instbitrange{19}{15} &
+\instbitrange{14}{12} &
+\instbitrange{11}{7} &
+\instbitrange{6}{0} \\
+\hline
+\multicolumn{1}{|c|}{funct7} &
+\multicolumn{1}{c|}{rs2} &
+\multicolumn{1}{c|}{Addr.\ Offset} &
+\multicolumn{1}{c|}{funct3} &
+\multicolumn{1}{c|}{rd} &
+\multicolumn{1}{c|}{opcode} \\
+\hline
+7 & 5 & 5 & 3 & 5 & 7 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Transformed virtual-machine load/store instruction (HLV, HLVX, HSV).
+All fields are the same as the trapping instruction except bits 19:15,
+Addr.\ Offset.}
+\label{transformedvmaccessinst}
+\end{figure*}
+
+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 {\tt mtval}
 or {\tt stval}) and the original virtual address.
-This difference can be nonzero only for an access or page fault that
-occurs for a misaligned memory access.
+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.
 
@@ -2815,14 +2996,14 @@ load/store is sufficient to prove that the trapping instruction is of the
 same kind.
 
 A future version of this standard may add information to the fields that
-are currently zeros;
-however, for backwards compatiblity, any such information will be for
+are currently zeros.
+However, for backwards compatiblity, any such information will be for
 performance purposes only and can safely be ignored.
 \end{commentary}
 
 For guest-page faults, the trap instruction register is written with a
 special pseudoinstruction value if:
-(a)~the faulting memory access is an implicit access for VS-level address
+(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
 {\tt mtval2} or {\tt htval}.
@@ -2836,11 +3017,11 @@ zero is not allowed.
 \hline
 Value            & Meaning \\
 \hline
-{\tt 0x00002000} & 32-bit read for VS-level address translation (RV32) \\
-{\tt 0x00002020} & 32-bit write for VS-level address translation (RV32) \\
+{\tt 0x00002000} & 32-bit read for VS-stage address translation (RV32) \\
+{\tt 0x00002020} & 32-bit write for VS-stage address translation (RV32) \\
 \hline
-{\tt 0x00003000} & 64-bit read for VS-level address translation (RV64) \\
-{\tt 0x00003020} & 64-bit write for VS-level address translation (RV64) \\
+{\tt 0x00003000} & 64-bit read for VS-stage address translation (RV64) \\
+{\tt 0x00003020} & 64-bit write for VS-stage address translation (RV64) \\
 \hline
 \end{tabular}
 \end{center}
@@ -2865,14 +3046,14 @@ Encoding         & Instruction \\ \hline
 \end{tabular}
 \end{center}
 \caption{Standard instructions corresponding to the special
-psuedoinstructions of Table~\ref{tab:pseudoinsts}.}
+pseudoinstructions of Table~\ref{tab:pseudoinsts}.}
 \label{tab:pseudoinsts-basis}
 \end{table*}
 
 A \textit{write} pseudoinstruction ({\tt 0x00002020} or {\tt 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-level address translation will
+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 \textit{write} case will never
@@ -2895,7 +3076,7 @@ There is no harm here in ignoring the atomicity requirement for page
 table updates, because a hypervisor is not expected in these
 circumstances to emulate an implicit memory access that fails.
 Rather, the hypervisor is given enough information about the faulting
-access to be able to make the memory accessible (e.g., by restoring a
+access to be able to make the memory accessible (e.g.\ by restoring a
 missing page of virtual memory) before resuming execution by retrying the
 faulting instruction.
 \end{commentary}
@@ -2907,8 +3088,6 @@ MRET first determines what the new operating mode will be according to
 the values of MPP and MPV in {\tt mstatus} or {\tt mstatush}, as encoded in
 Table~\ref{h-mpp}.
 MRET then in {\tt mstatus}/{\tt mstatush} sets MPV=0, MPP=0, MIE=MPIE, and MPIE=1.
-If the new operating mode will be U, VS, or VU, MRET also sets
-{\tt hstatus}.SPRV=0.
 Lastly, MRET sets the virtualization and privilege modes as previously
 determined, and sets {\tt pc}={\tt mepc}.
 
@@ -2918,15 +3097,11 @@ 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 operating mode will be according to the values in
 {\tt hstatus}.SPV and {\tt sstatus}.SPP, as encoded in Table~\ref{h-spp}.
-SRET then sets {\tt hstatus}.SPV={\tt hstatus}.SP2V,
-{\tt sstatus}.SPP={\tt hstatus}.SP2P, {\tt hstatus}.SP2V=0,
-{\tt hstatus}.SP2P=0, {\tt sstatus}.SIE={\tt sstatus}.SPIE, and
-{\tt sstatus}.SPIE=1.
-If the new operating mode will be U, VS, or VU, SRET also sets
-{\tt hstatus}.SPRV=0.
+SRET then sets {\tt hstatus}.SPV=0, and in {\tt sstatus} sets SPP=0,
+SIE=SPIE, and SPIE=1.
 Lastly, SRET sets the virtualization and privilege modes as previously
 determined, and sets {\tt pc}={\tt sepc}.
 
 When executed in VS-mode (i.e., V=1), SRET sets the privilege mode according to
-Table~\ref{h-vspp}, then in {\tt vsstatus} sets SPP=0, SIE=SPIE, and SPIE=1, and
+Table~\ref{h-vspp}, in {\tt vsstatus} sets SPP=0, SIE=SPIE, and SPIE=1, and
 lastly sets {\tt pc}={\tt vsepc}.
diff --git a/src/priv-preface.tex b/src/priv-preface.tex
index 2840066..29d600a 100644
--- a/src/priv-preface.tex
+++ b/src/priv-preface.tex
@@ -14,7 +14,7 @@ modules:
     \hline
     \em Machine ISA    & \em 1.12 & \em Draft \\
     \em Supervisor ISA & \em 1.12 & \em Draft \\
-    \em Hypervisor ISA & \em 0.5  & \em Draft \\
+    \em Hypervisor ISA & \em 0.6  & \em Draft \\
     \em N Extension    & \em 1.1 & \em Draft \\
     \hline
   \end{tabular}