diff options
| -rw-r--r-- | src/hypervisor.tex | 669 | ||||
| -rw-r--r-- | src/priv-preface.tex | 2 |
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} |