path: root/src/hypervisor.tex

\chapter{Hypervisor Extension, Version 1.0.0-rc}
\label{hypervisor}

This chapter is in the Frozen state.
A substantive change that is not backward-compatible is highly
unlikely, and will occur only as the result of some truly critical
issue being identified.
For more info see:  \texttt{http://riscv.org/spec-state}.

This chapter describes the RISC-V hypervisor extension, which virtualizes the
supervisor-level architecture to support the efficient hosting of guest
operating systems atop a type-1 or type-2 hypervisor.
The hypervisor extension changes supervisor mode into
{\em hypervisor-extended supervisor mode} (HS-mode, or {\em hypervisor
mode} for short), where a hypervisor or a hosting-capable operating system
runs.  The hypervisor extension also adds another stage of address translation,
from {\em guest physical addresses} to supervisor physical addresses,
to virtualize the
memory and memory-mapped I/O subsystems for a guest operating system.  HS-mode
acts the same as S-mode, but with additional instructions and CSRs that control
the new stage of address translation and support hosting a guest OS in virtual
S-mode (VS-mode).
Regular S-mode operating systems can execute without modification either in
HS-mode or as VS-mode guests.

In HS-mode, an OS or hypervisor interacts with the machine through the same
SBI as an OS normally does from S-mode.  An HS-mode hypervisor is expected to
implement the SBI for its VS-mode guest.

The hypervisor extension depends on an ``I'' base integer ISA with
32 {\tt x} registers (RV32I or RV64I), not RV32E, which has only
16 {\tt x} registers.
CSR {\tt mtval} must not be read-only zero, and
standard page-based address translation must be supported, either
Sv32 for RV32, or a minimum of Sv39 for RV64.

The hypervisor extension is enabled by setting bit 7 in the {\tt misa} CSR,
which corresponds to the letter H.
RISC-V harts that implement the hypervisor extension are encouraged
not to hardwire {\tt misa}[7], so that the extension may be disabled.

\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.
The hypervisor extension improves virtualization performance by
reducing the frequency of these traps.

The hypervisor extension has been designed to be efficiently
emulable on platforms that do not implement the extension, by running
the hypervisor in S-mode and trapping into M-mode for hypervisor CSR accesses
and to maintain shadow page tables.  The majority of CSR accesses for
type-2 hypervisors are valid S-mode accesses so need not be trapped.
Hypervisors can support nested virtualization analogously.
\end{commentary}

\section{Privilege Modes}

The current {\em virtualization mode}, denoted V, indicates whether the hart
is currently executing in a guest.
When V=1, the hart is either in virtual S-mode (VS-mode), or in virtual U-mode
(VU-mode) atop a guest OS running in VS-mode.
When V=0, the hart is either in M-mode, in HS-mode, or in U-mode atop an OS
running in HS-mode.
The virtualization mode also indicates whether two-stage address translation
is active (V=1) or inactive (V=0).  Table~\ref{tab:HPrivModes} lists the
possible privilege modes of a RISC-V hart with the hypervisor extension.

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|c|c||l|l|l|}
  \hline
   Virtualization & Nominal   & \multirow{2}{*}{Abbreviation} & \multirow{2}{*}{Name} & Two-Stage \\
   Mode (V)       & Privilege &                               &                       & Translation \\ \hline
   0              & U         & U-mode  & User mode & Off \\
   0              & S         & HS-mode & Hypervisor-extended supervisor mode & Off \\
   0              & M         & M-mode  & Machine mode & Off \\
  \hline
   1              & U         & VU-mode & Virtual user mode & On \\
   1              & S         & VS-mode & Virtual supervisor mode & On \\
  \hline
 \end{tabular}
\end{center}
\caption{Privilege modes with the hypervisor extension.}
\label{tab:HPrivModes}
\end{table*}

For privilege modes U and VU, the \textit{nominal privilege mode} is~U,
and for privilege modes HS and VS, the nominal privilege mode is~S.

HS-mode is more privileged
than VS-mode, and VS-mode is more privileged than VU-mode.
VS-mode interrupts are globally disabled when executing in U-mode.

\begin{commentary}
This description does not consider the possibility of U-mode or VU-mode interrupts and will be revised if an extension for user-level interrupts is adopted.
\end{commentary}

\section{Hypervisor and Virtual Supervisor CSRs}

An OS or hypervisor running in HS-mode uses the supervisor CSRs to interact with the exception,
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 hvip}, {\tt hip}, {\tt hie},
{\tt hgeip}, {\tt hgeie}, {\tt henvcfg}, {\tt henvcfgh},
{\tt hcounteren}, {\tt htimedelta}, {\tt htimedeltah}, {\tt htval},
{\tt htinst}, and {\tt hgatp}.

Furthermore, several {\em virtual supervisor} CSRs (VS CSRs) are replicas
of the normal supervisor CSRs.
For example, {\tt vsstatus} is the VS CSR that duplicates the usual
{\tt sstatus} CSR.

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

While V=1, the normal HS-level supervisor CSRs that are replaced by
VS CSRs retain their values but do
not affect the behavior of the machine unless specifically documented to
do so.
Conversely, when V=0, the VS CSRs do not ordinarily affect the behavior of
the machine other than being readable and writable by CSR instructions.

Some standard supervisor CSRs ({\tt senvcfg},
{\tt scounteren}, and {\tt scontext},
possibly others) have no matching VS CSR.
These supervisor CSRs continue to have their usual function and
accessibility even when V=1, except with VS-mode and VU-mode substituting for
HS-mode and U-mode.
Hypervisor software is expected to manually swap the contents of these
registers as needed.

\begin{commentary}
Matching VS CSRs exist only for the supervisor CSRs that must be
duplicated, which are mainly those that get automatically written by
traps or that impact instruction execution immediately after trap entry
and/or right before SRET, when software alone is unable to swap a CSR at
exactly the right moment.
Currently, most supervisor CSRs fall into this category, but future ones
might not.
\end{commentary}

In this chapter, we use the term {\em HSXLEN} to refer to the effective XLEN
when executing in HS-mode, and {\em VSXLEN} to refer to the effective
XLEN when executing in VS-mode.

\subsection{Hypervisor Status Register ({\tt hstatus})}

The {\tt hstatus} register is an HSXLEN-bit read/write register
formatted as shown in Figure~\ref{hstatusreg-rv32} when HSXLEN=32 and
Figure~\ref{hstatusreg} when HSXLEN=64.
The {\tt hstatus}
register provides facilities analogous to the {\tt mstatus} register
for tracking and controlling the exception behavior of a VS-mode guest.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\scalebox{0.95}{
\begin{tabular}{YcccWYccWcccccF}
\\
\instbitrange{31}{23} &
\instbit{22} &
\instbit{21} &
\instbit{20} &
\instbitrange{19}{18} &
\instbitrange{17}{12} &
\instbitrange{11}{10} &
\instbit{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbitrange{4}{0} \\
\hline
\multicolumn{1}{|c|}{\wpri} &
\multicolumn{1}{c|}{VTSR} &
\multicolumn{1}{c|}{VTW} &
\multicolumn{1}{c|}{VTVM} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{VGEIN[5:0]} &
\multicolumn{1}{c|}{\wpri} &
\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
9 & 1 & 1 & 1 & 2 & 6 & 2 & 1 & 1 & 1 & 1 & 1 & 5 \\
\end{tabular}}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor status register ({\tt hstatus}) when HSXLEN=32.}
\label{hstatusreg-rv32}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{KFScccc}
\\
\instbitrange{HSXLEN-1}{34} &
\instbitrange{33}{32} &
\instbitrange{31}{23} &
\instbit{22} &
\instbit{21} &
\instbit{20} &
 \\
\hline
\multicolumn{1}{|c|}{\wpri} &
\multicolumn{1}{c|}{VSXL[1:0]} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{VTSR} &
\multicolumn{1}{c|}{VTW} &
\multicolumn{1}{c|}{VTVM} &
 \\
\hline
HSXLEN-34 & 2 & 9 & 1 & 1 & 1 & \\
\end{tabular}
\begin{tabular}{cWRWcccccY}
\\
&
\instbitrange{19}{18} &
\instbitrange{17}{12} &
\instbitrange{11}{10} &
\instbit{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbitrange{4}{0} \\
\hline
 &
\multicolumn{1}{|c|}{\wpri} &
\multicolumn{1}{c|}{VGEIN[5:0]} &
\multicolumn{1}{c|}{\wpri} &
\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 & 6 & 2 & 1 & 1 & 1 & 1 & 1 & 5 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor status register ({\tt hstatus}) when HSXLEN=64.}
\label{hstatusreg}
\end{figure*}

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

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

The {\tt hstatus} fields VTSR, VTW, and VTVM are defined analogously to the
{\tt mstatus} fields TSR, TW, and TVM, but affect execution only in VS-mode,
and cause virtual instruction exceptions instead of illegal instruction
exceptions.
When VTSR=1, an attempt in VS-mode to execute SRET raises a virtual
instruction exception.
When VTW=1 (and assuming {\tt mstatus}.TW=0), an attempt in VS-mode to
execute WFI raises a virtual instruction exception if the WFI does not
complete within an implementation-specific, bounded time limit.
When VTVM=1, an attempt in VS-mode to execute SFENCE.VMA or SINVAL.VMA or to
access CSR {\tt satp} raises a virtual instruction exception.

The VGEIN (Virtual Guest External Interrupt Number) field selects a guest
external interrupt source for VS-level external interrupts.
VGEIN is a \wlrl\ field that must be able to hold values between zero
and the maximum guest external interrupt number (known as GEILEN),
inclusive.
When VGEIN=0, no guest external interrupt source is selected for VS-level
external interrupts.
GEILEN may be zero, in which case VGEIN may be read-only zero.
Guest external interrupts are explained in
Section~\ref{sec:hgeinterruptregs}, and the use of VGEIN is covered
further in Section~\ref{sec:hinterruptregs}.

Field HU (Hypervisor in U-mode) controls whether the virtual-machine
load/store instructions, HLV, HLVX, and HSV, can be used also in U-mode.
When HU=1, these instructions can be executed in U-mode the same as in
HS-mode.
When HU=0, all hypervisor instructions cause an illegal instruction 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 (nominal) 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 V=1 and a trap is taken into HS-mode, bit SPVP (Supervisor Previous
Virtual Privilege) is set to the nominal privilege mode at the time of the trap,
the same as {\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 (breakpoint, address misaligned,
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 breakpoint and memory access traps
that write a nonzero value to {\tt stval},
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.
If VSBE=0, explicit load and store memory accesses made from VS-mode are
little-endian, and if VSBE=1, they are big-endian.
VSBE also controls the endianness of all implicit accesses to VS-level
memory management data structures, such as page tables.
An implementation may make VSBE a read-only field that always specifies
the same endianness as HS-mode.

\subsection{Hypervisor Trap Delegation Registers ({\tt hedeleg} and {\tt hideleg})}

Registers {\tt hedeleg} and {\tt hideleg} are HSXLEN-bit read/write
registers, formatted as shown in Figures \ref{hedelegreg} and
\ref{hidelegreg} respectively.
By default, all traps at any privilege level are handled in M-mode, though
M-mode usually uses the {\tt medeleg} and {\tt mideleg} CSRs to delegate
some traps to HS-mode.  The {\tt hedeleg} and {\tt hideleg} CSRs allow these
traps to be further delegated to a VS-mode guest; their layout is the same
as {\tt medeleg} and {\tt mideleg}.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Synchronous Exceptions (\warl)} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor exception delegation register ({\tt hedeleg}).}
\label{hedelegreg}
\end{figure}

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupts (\warl)} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor interrupt delegation register ({\tt hideleg}).}
\label{hidelegreg}
\end{figure}

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|r|l|l|}
\hline
Bit & Attribute   & Corresponding Exception \\
\hline
 0  & (See text)  & Instruction address misaligned \\
 1  & Writable    & Instruction access fault \\
 2  & Writable    & Illegal instruction \\
 3  & Writable    & Breakpoint \\
 4  & Writable    & Load address misaligned \\
 5  & Writable    & Load access fault \\
 6  & Writable    & Store/AMO address misaligned \\
 7  & Writable    & Store/AMO access fault \\
 8  & Writable    & Environment call from U-mode or VU-mode \\
 9  & Read-only 0 & Environment call from HS-mode \\
10  & Read-only 0 & Environment call from VS-mode \\
11  & Read-only 0 & Environment call from M-mode \\
12  & Writable    & Instruction page fault \\
13  & Writable    & Load page fault \\
15  & Writable    & Store/AMO page fault \\
20  & Read-only 0 & Instruction guest-page fault \\
21  & Read-only 0 & Load guest-page fault \\
22  & Read-only 0 & Virtual instruction \\
23  & Read-only 0 & Store/AMO guest-page fault \\
\hline
\end{tabular}
\end{center}
\caption{Bits of {\tt hedeleg} that must be writable or must be read-only
zero.}
\label{tab:hedeleg-bits}
\end{table*}

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

\begin{commentary}
Requiring that certain bits of {\tt hedeleg} be writable reduces some of
the burden on a hypervisor to handle variations of implementation.
\end{commentary}

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

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

\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.
Bits of {\tt hvip} that are not writable are read-only 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}.
Bits VSEIP, VSTIP, and VSSIP of {\tt hvip} are writable.
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.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupts (\warl)} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor interrupt-pending register ({\tt hip}).}
\label{hipreg}
\end{figure}

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupts (\warl)} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor interrupt-enable register ({\tt hie}).}
\label{hiereg}
\end{figure}

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

\begin{commentary}
The active bits of {\tt hip} and {\tt hie} cannot be placed in HS-level's
{\tt sip} and {\tt sie} because doing so would make it impossible for
software to emulate the hypervisor extension on platforms that do not
implement it in hardware.
\end{commentary}

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

If bit~\textit{i} of {\tt sie} is read-only zero, the same bit in
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, 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).

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

The standard portions (bits 15:0) of registers {\tt hip} and {\tt hie}
are formatted as shown in Figures \ref{hipreg-standard} and
\ref{hiereg-standard} respectively.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{FcccFcFcW}
\instbitrange{15}{13} &
\instbit{12} &
\instbit{11} &
\instbit{10} &
\instbitrange{9}{7} &
\instbit{6} &
\instbitrange{5}{3} &
\instbit{2} &
\instbitrange{1}{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SGEIP} &
\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
3 & 1 & 1 & 1 & 3 & 1 & 3 & 1 & 2 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt hip}.}
\label{hipreg-standard}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{FcccFcFcW}
\instbitrange{15}{13} &
\instbit{12} &
\instbit{11} &
\instbit{10} &
\instbitrange{9}{7} &
\instbit{6} &
\instbitrange{5}{3} &
\instbit{2} &
\instbitrange{1}{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SGEIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{VSEIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{VSTIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{VSSIE} &
\multicolumn{1}{c|}{0} \\
\hline
3 & 1 & 1 & 1 & 3 & 1 & 3 & 1 & 2 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt hie}.}
\label{hiereg-standard}
\end{figure*}

Bits {\tt hip}.SGEIP and {\tt hie}.SGEIE are the interrupt-pending and
interrupt-enable bits for guest external interrupts at supervisor level
(HS-level).
SGEIP is read-only in {\tt hip}, and is 1 if and only if the bitwise
logical-AND of CSRs {\tt hgeip} and {\tt hgeie} is nonzero in any bit.
(See Section~\ref{sec:hgeinterruptregs}.)

Bits {\tt hip}.VSEIP and {\tt hie}.VSEIE are the interrupt-pending and
interrupt-enable bits for VS-level external interrupts.
VSEIP is read-only in {\tt hip}, and is the logical-OR of these interrupt
sources:
\begin{tightlist}
\item
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}

Bits {\tt hip}.VSTIP and {\tt hie}.VSTIE are the interrupt-pending and
interrupt-enable bits for VS-level timer interrupts.
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 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.

\subsection{Hypervisor Guest External Interrupt Registers ({\tt hgeip} and {\tt hgeie})}
\label{sec:hgeinterruptregs}

The {\tt hgeip} register is an HSXLEN-bit read-only register, formatted
as shown in Figure~\ref{hgeipreg}, that indicates pending guest external
interrupts for this hart.
The {\tt hgeie} register is an HSXLEN-bit read/write register, formatted
as shown in Figure~\ref{hgeiereg}, that contains enable bits for the
guest external interrupts at this hart.
Guest external interrupt number \textit{i} corresponds with
bit~\textit{i} in both {\tt hgeip} and {\tt hgeie}.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}Jc}
\instbitrange{HSXLEN-1}{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{Guest External Interrupts} &
\multicolumn{1}{c|}{0} \\
\hline
HSXLEN-1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor guest external interrupt-pending register ({\tt hgeip}).}
\label{hgeipreg}
\end{figure}

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}Jc}
\instbitrange{HSXLEN-1}{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{Guest External Interrupts (\warl)} &
\multicolumn{1}{c|}{0} \\
\hline
HSXLEN-1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor guest external interrupt-enable register ({\tt hgeie}).}
\label{hgeiereg}
\end{figure}

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

\begin{commentary}
Support for guest external interrupts requires an interrupt controller
that can collect virtual-machine-directed interrupts separately from
other interrupts.
\end{commentary}

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

\begin{commentary}
The set of guest external interrupts received and handled at one physical
hart may differ from those received at other harts.
Guest external interrupt number~\textit{i} at one physical hart is
typically expected not to be the same as guest external
interrupt~\textit{i} at any other hart.
For any one physical hart, the maximum number of virtual harts that may
directly receive guest external interrupts is limited by GEILEN.
The maximum this number can be for any implementation is 31 for RV32 and
63 for RV64, per physical hart.

A hypervisor is always free to \emph{emulate} devices for any number of
virtual harts without being limited by GEILEN.
Only direct pass-through (direct assignment) of interrupts is affected by
the GEILEN limit, and the limit is on the number of virtual harts
receiving such interrupts, not the number of distinct interrupts
received.
The number of distinct interrupts a single virtual hart may receive is
determined by the interrupt controller.
\end{commentary}

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

\subsection{%
 Hypervisor Environment Configuration Registers
 ({\tt henvcfg} and {\tt henvcfgh})%
}

The {\tt henvcfg} CSR is an HSXLEN-bit read/write register,
formatted for HSXLEN=64 as shown in Figure~\ref{fig:henvcfg},
that controls certain
characteristics of the execution environment when virtualization mode
V=1.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{c@{}Kcc@{}W@{}Wc}
\instbit{63} &
\instbitrange{62}{8} &
\instbit{7} &
\instbit{6} &
\instbitrange{5}{4} &
\instbitrange{3}{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{VSTCE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{CBZE} &
\multicolumn{1}{c|}{CBCFE} &
\multicolumn{1}{c|}{CBIE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{FIOM} \\
\hline
1 & 55 & 1 & 1 & 2 & 3 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor environment configuration register ({\tt henvcfg}) for HSXLEN=64.}
\label{fig:henvcfg}
\end{figure}

If bit FIOM (Fence of I/O implies Memory) is set to one in
{\tt henvcfg}, FENCE instructions executed when V=1 are modified
so the requirement to order accesses to device I/O implies also the
requirement to order main memory accesses.
Table~\ref{tab:henvcfg-FIOM} details the modified interpretation of
FENCE instruction bits PI, PO, SI, and SO when FIOM=1 and V=1.

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

\begin{table}[h!]
\begin{center}
\begin{tabular}{|c|l|}
\hline
Instruction bit & Meaning when set \\
\hline
PI & Predecessor device input and memory reads   (PR implied) \\
PO & Predecessor device output and memory writes (PW implied) \\
\hline
SI & Successor device input and memory reads     (SR implied) \\
SO & Successor device output and memory writes   (SW implied) \\
\hline
\end{tabular}
\end{center}
\vspace{-0.1in}
\caption{%
Modified interpretation of FENCE predecessor and successor sets when
FIOM=1 and virtualization mode V=1.%
}
\label{tab:henvcfg-FIOM}
\end{table}

The definition of the VSTCE field will be furnished by the
forthcoming Sstc extension.
Its allocation within {\tt henvcfg} may change prior to the ratification
of that extension.

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

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

When HSXLEN=32, {\tt henvcfg} contains the same fields as bits 31:0
of {\tt henvcfg} when HSXLEN=64.
Additionally, when HSXLEN=32, {\tt henvcfgh} is a 32-bit read/write register that
contains the same fields as bits 63:32 of {\tt henvcfg} when
HSXLEN=64.
Register {\tt henvcfgh} does not exist when HSXLEN=64.

\subsection{Hypervisor Counter-Enable Register ({\tt hcounteren})}

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

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{cccMcccccc}
\instbit{31} &
\instbit{30} &
\instbit{29} &
\instbitrange{28}{6} &
\instbit{5} &
\instbit{4} &
\instbit{3} &
\instbit{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{HPM31} &
\multicolumn{1}{c|}{HPM30} &
\multicolumn{1}{c|}{HPM29} &
\multicolumn{1}{c|}{...} &
\multicolumn{1}{c|}{HPM5} &
\multicolumn{1}{c|}{HPM4} &
\multicolumn{1}{c|}{HPM3} &
\multicolumn{1}{c|}{IR} &
\multicolumn{1}{c|}{TM} &
\multicolumn{1}{c|}{CY} \\
\hline
1 & 1 & 1 & 23 & 1 & 1 & 1 & 1 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor counter-enable register ({\tt hcounteren}).}
\label{hcounteren}
\end{figure*}

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

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

\subsection{Hypervisor Time Delta Registers ({\tt htimedelta}, {\tt htimedeltah})}

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

\begin{commentary}
Because overflow is ignored when summing {\tt htimedelta} and {\tt time},
large values of {\tt htimedelta} may be used to represent negative time
offsets.
\end{commentary}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{63}{0} \\
\hline
\multicolumn{1}{|c|}{\tt htimedelta} \\
\hline
64 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor time delta register, HSXLEN=64.}
\label{hdeltareg}
\end{figure*}

For HSXLEN=32 only, {\tt htimedelta} holds the lower 32 bits of the
delta, and {\tt htimedeltah} holds the upper 32 bits of the delta.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{31}{0} \\
\hline
\multicolumn{1}{|c|}{\tt htimedelta} \\
\hline
\multicolumn{1}{|c|}{\tt htimedeltah} \\
\hline
32 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor time delta registers, HSXLEN=32.}
\label{hdeltahreg}
\end{figure*}

\subsection{Hypervisor Trap Value Register ({\tt htval})}

The {\tt htval} register is an HSXLEN-bit read/write register formatted
as shown in Figure~\ref{htvalreg}.
When a trap is taken into HS-mode, {\tt htval} is written with additional
exception-specific information, alongside {\tt stval}, to assist software
in handling the trap.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt htval} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor trap value register ({\tt htval}).}
\label{htvalreg}
\end{figure*}

When a guest-page-fault trap is taken into HS-mode, {\tt htval} is
written with either zero or the guest physical address that faulted,
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.

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, a nonzero {\tt htval} corresponds to the faulting portion
of the instruction as indicated by the virtual address in {\tt stval}.

\begin{commentary}
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},
\ref{sec:sv48}, and~\ref{sec:sv57}).

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-stage address
translation, the least-significant two bits are instead zeros.
These cases can be distinguished using the value provided in register
{\tt htinst}.
\end{commentary}

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

\begin{commentary}
Unless it has reason to assume otherwise (such as a platform standard),
software that writes a value to {\tt htval} should read back from
{\tt htval} to confirm the stored value.
\end{commentary}

\subsection{Hypervisor Trap Instruction Register ({\tt htinst})}

The {\tt htinst} register is an HSXLEN-bit read/write register formatted
as shown in Figure~\ref{htinstreg}.
When a trap is taken into HS-mode, {\tt htinst} is written with a value
that, if nonzero, provides information about the instruction that
trapped, to assist software in handling the trap.
The values that may be written to {\tt htinst} on a trap are documented
in Section~\ref{sec:tinst-vals}.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{HSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt htinst} \\
\hline
HSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor trap instruction register ({\tt htinst}).}
\label{htinstreg}
\end{figure*}

{\tt htinst} is a \warl\ register that need only be able to hold the
values that the implementation may automatically write to it on a trap.

\subsection{Hypervisor Guest Address Translation and Protection Register ({\tt hgatp})}
\label{sec:hgatp}

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 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;
and the MODE field, which selects the address-translation scheme for guest
physical addresses.
When {\tt mstatus}.TVM=1, attempts to read or write {\tt hgatp} while executing
in HS-mode will raise an illegal instruction exception.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{cY@{}E@{}K}
\instbit{31} &
\instbitrange{30}{29} &
\instbitrange{28}{22} &
\instbitrange{21}{0} \\
\hline
\multicolumn{1}{|c|}{MODE} &
\multicolumn{1}{c|}{0 (\warl)} &
\multicolumn{1}{c|}{VMID (\warl)} &
\multicolumn{1}{c|}{PPN  (\warl)} \\
\hline
1 & 2 & 7 & 22 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor guest address translation and protection register
{\tt hgatp} when HSXLEN=32.}
\label{rv32hgatp}
\end{figure}

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}S@{}Y@{}E@{}K}
\instbitrange{63}{60} &
\instbitrange{59}{58} &
\instbitrange{57}{44} &
\instbitrange{43}{0} \\
\hline
\multicolumn{1}{|c|}{MODE (\warl)} &
\multicolumn{1}{c|}{0 (\warl)} &
\multicolumn{1}{c|}{VMID (\warl)} &
\multicolumn{1}{c|}{PPN  (\warl)} \\
\hline
4 & 2 & 14 & 44 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Hypervisor guest address translation and protection register
{\tt hgatp} when HSXLEN=64, for MODE values Bare, Sv39x4, Sv48x4, and Sv57x4.}
\label{rv64hgatp}
\end{figure}

Table~\ref{tab:hgatp-mode} shows the encodings of the MODE field when HSXLEN=32 and
HSXLEN=64.
When MODE=Bare, guest physical addresses are equal to supervisor physical
addresses, and there is no further memory protection for a guest virtual
machine beyond the physical memory protection scheme described in
Section~\ref{sec:pmp}.
In this case, the remaining fields in {\tt hgatp} must be set to zeros.

When HSXLEN=32, the only other valid setting for MODE is Sv32x4, which is a
modification of the usual Sv32 paged virtual-memory scheme, extended to support
34-bit guest physical addresses.
When HSXLEN=64, modes Sv39x4, Sv48x4, and Sv57x4 are defined as modifications of the
Sv39, Sv48, and Sv57 paged virtual-memory schemes.
All of these paged virtual-memory schemes are described in
Section~\ref{sec:guest-addr-translation}.

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

\begin{table}[h]
\begin{center}
\begin{tabular}{|c|c|l|}
\hline
\multicolumn{3}{|c|}{HSXLEN=32} \\
\hline
Value  & Name & Description \\
\hline
0      & Bare   & No translation or protection. \\
1      & Sv32x4 & Page-based 34-bit virtual addressing (2-bit extension of Sv32). \\
\hline \hline
\multicolumn{3}{|c|}{HSXLEN=64} \\
\hline
Value  & Name & Description \\
\hline
0      & Bare   & No translation or protection. \\
1--7   & ---    & {\em Reserved} \\
8      & Sv39x4 & Page-based 41-bit virtual addressing (2-bit extension of Sv39). \\
9      & Sv48x4 & Page-based 50-bit virtual addressing (2-bit extension of Sv48). \\
10     & Sv57x4 & Page-based 59-bit virtual addressing (2-bit extension of Sv57). \\
11--15 & ---    & {\em Reserved} \\
\hline
\end{tabular}
\end{center}
\caption{Encoding of {\tt hgatp} MODE field.}
\label{tab:hgatp-mode}
\end{table}

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

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

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

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

The {\tt hgatp} register is considered {\em active} for the purposes of the
address-translation algorithm when the effective privilege mode is VS-mode or
VU-mode.  The {\tt hgatp} register is also considered briefly active when
executing a virtual-machine load/store instruction (HLV, HLVX, or HSV), and
hence the address-translation algorithm may be executed speculatively for any
guest virtual address when such an instruction is executed.

\begin{commentary}
Defining there to be a brief window during which {\tt hgatp} is active while
executing an HLV, HLVX, or HSV instruction allows the implementation to
prefetch adjacent PTEs in the same cache line, or to prefetch translations
predicted to be needed by future HLV, HLVX, or HSV instructions, for example.
\end{commentary}

Note that writing {\tt hgatp} does not imply any ordering constraints between
page-table updates and subsequent G-stage address translations.
If the new virtual machine's guest physical page tables have been modified,
or if a VMID is reused,
it may be necessary to execute an HFENCE.GVMA instruction
(see Section~\ref{sec:hfence.vma}) before or after writing {\tt hgatp}.

\subsection{Virtual Supervisor Status Register ({\tt vsstatus})}

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-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
{\tt vsstatus} instead.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{cEcccc}
\\
\instbit{31} &
\instbitrange{30}{20} &
\instbit{19} &
\instbit{18} &
\instbit{17} &
 \\
\hline
\multicolumn{1}{|c|}{SD} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{MXR} &
\multicolumn{1}{c|}{SUM} &
\multicolumn{1}{c|}{\wpri} &
 \\
\hline
1 & 11 & 1 & 1 & 1 & \\
\end{tabular}
\begin{tabular}{cWWWWccccWcc}
\\
&
\instbitrange{16}{15} &
\instbitrange{14}{13} &
\instbitrange{12}{11} &
\instbitrange{10}{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbitrange{4}{2} &
\instbit{1} &
\instbit{0} \\
\hline
 &
\multicolumn{1}{|c|}{XS[1:0]} &
\multicolumn{1}{c|}{FS[1:0]} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SPP} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{UBE} &
\multicolumn{1}{c|}{SPIE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SIE} &
\multicolumn{1}{c|}{\wpri} \\
\hline
 & 2 & 2 & 2 & 2 & 1 & 1 & 1 & 1 & 3 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor status register ({\tt vsstatus}) when VSXLEN=32.}
\label{vsstatusreg-rv32}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{cMFScccc}
\\
\instbit{VSXLEN-1} &
\instbitrange{VSXLEN-2}{34} &
\instbitrange{33}{32} &
\instbitrange{31}{20} &
\instbit{19} &
\instbit{18} &
\instbit{17} &
 \\
\hline
\multicolumn{1}{|c|}{SD} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{UXL[1:0]} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{MXR} &
\multicolumn{1}{c|}{SUM} &
\multicolumn{1}{c|}{\wpri} &
 \\
\hline
1 & VSXLEN-35 & 2 & 12 & 1 & 1 & 1 & \\
\end{tabular}
\begin{tabular}{cWWWWccccWcc}
\\
&
\instbitrange{16}{15} &
\instbitrange{14}{13} &
\instbitrange{12}{11} &
\instbitrange{10}{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbitrange{4}{2} &
\instbit{1} &
\instbit{0} \\
\hline
 &
\multicolumn{1}{|c|}{XS[1:0]} &
\multicolumn{1}{c|}{FS[1:0]} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SPP} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{UBE} &
\multicolumn{1}{c|}{SPIE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SIE} &
\multicolumn{1}{c|}{\wpri} \\
\hline
 & 2 & 2 & 2 & 2 & 1 & 1 & 1 & 1 & 3 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor status register ({\tt vsstatus}) when VSXLEN=64.}
\label{vsstatusreg}
\end{figure*}

The UXL field controls the effective XLEN for VU-mode, which may differ
from the XLEN for VS-mode (VSXLEN).
When VSXLEN=32, the UXL field does not exist, and VU-mode XLEN=32.
When VSXLEN=64, UXL is a \warl\ field that is encoded the same as the MXL
field of {\tt misa}, shown in Table~\ref{misabase} on
page~\pageref{misabase}.
In particular, an implementation may make UXL be a read-only copy of
field VSXL of {\tt hstatus}, forcing VU-mode XLEN=VSXLEN.

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

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

\begin{commentary}
For a hypervisor to benefit from the extension context status, it must
have its own copy in the HS-level {\tt sstatus}, maintained independently
of a guest OS running in VS-mode.
While a version of the extension context status obviously must exist in
{\tt vsstatus} for VS-mode, a hypervisor cannot rely on this version
being maintained correctly, given that VS-level software can change
{\tt vsstatus}.FS arbitrarily.
If the HS-level {\tt sstatus}.FS were not independently active and
maintained by the hardware in parallel with {\tt vsstatus}.FS while V=1,
hypervisors would always be forced to conservatively swap all
floating-point state when context-switching between virtual machines.
\end{commentary}

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

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

When V=0, {\tt vsstatus} does not directly affect the behavior of the machine,
unless a virtual-machine load/store (HLV, HLVX, or HSV)
or the MPRV feature in the {\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})}

The {\tt vsip} and {\tt vsie} registers are VSXLEN-bit read/write
registers that are VS-mode's versions of supervisor CSRs {\tt sip} and
{\tt sie}, formatted as shown in Figures \ref{vsipreg} and \ref{vsiereg}
respectively.
When V=1, {\tt vsip} and {\tt vsie} substitute for the usual {\tt sip}
and {\tt sie}, so instructions that normally read or modify
{\tt sip}/{\tt sie} actually access {\tt vsip}/{\tt vsie} instead.
However, interrupts directed to HS-level continue to be
indicated in the HS-level {\tt sip} register, not in {\tt vsip}, when
V=1.

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{VSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupts (\warl)} \\
\hline
VSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor interrupt-pending register ({\tt vsip}).}
\label{vsipreg}
\end{figure}

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{VSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupts (\warl)} \\
\hline
VSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor interrupt-enable register ({\tt vsie}).}
\label{vsiereg}
\end{figure}

The standard portions (bits 15:0) of registers {\tt vsip} and {\tt vsie}
are formatted as shown in Figures \ref{vsipreg-standard} and
\ref{vsiereg-standard} respectively.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{ScFcFcc}
\instbitrange{15}{10} &
\instbit{9} &
\instbitrange{8}{6} &
\instbit{5} &
\instbitrange{4}{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SEIP} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{STIP} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{SSIP} &
\multicolumn{1}{c|}{0} \\
\hline
6 & 1 & 3 & 1 & 3 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt vsip}.}
\label{vsipreg-standard}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{ScFcFcc}
\instbitrange{15}{10} &
\instbit{9} &
\instbitrange{8}{6} &
\instbit{5} &
\instbitrange{4}{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SEIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{STIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{SSIE} &
\multicolumn{1}{c|}{0} \\
\hline
6 & 1 & 3 & 1 & 3 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt vsie}.}
\label{vsiereg-standard}
\end{figure*}

When bit 10 of {\tt hideleg} is zero, {\tt vsip}.SEIP and {\tt vsie}.SEIE
are read-only zeros.
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 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 of {\tt hip}.VSSIP
and {\tt hie}.VSSIE.

\subsection{Virtual Supervisor Trap Vector Base Address Register ({\tt vstvec})}

The {\tt vstvec} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt stvec}, formatted as shown
in Figure~\ref{vstvecreg}.
When V=1, {\tt vstvec} substitutes for the usual {\tt stvec}, so
instructions that normally read or modify {\tt stvec} actually access
{\tt vstvec} instead.
When V=0, {\tt vstvec} does not directly affect the behavior of the
machine.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{J@{}R}
\instbitrange{VSXLEN-1}{2} &
\instbitrange{1}{0} \\
\hline
\multicolumn{1}{|c|}{BASE[VSXLEN-1:2] (\warl)} &
\multicolumn{1}{c|}{MODE (\warl)} \\
\hline
VSXLEN-2 & 2 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor trap vector base address register ({\tt vstvec}).}
\label{vstvecreg}
\end{figure*}

\subsection{Virtual Supervisor Scratch Register ({\tt vsscratch})}

The {\tt vsscratch} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt sscratch}, formatted as
shown in Figure~\ref{vsscratchreg}.
When V=1, {\tt vsscratch} substitutes for the usual {\tt sscratch}, so
instructions that normally read or modify {\tt sscratch} actually access
{\tt vsscratch} instead.
The contents of {\tt vsscratch} never directly affect the behavior of
the machine.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{VSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt vsscratch} \\
\hline
VSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor scratch register ({\tt vsscratch}).}
\label{vsscratchreg}
\end{figure*}

\subsection{Virtual Supervisor Exception Program Counter ({\tt vsepc})}

The {\tt vsepc} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt sepc}, formatted as shown
in Figure~\ref{vsepcreg}.
When V=1, {\tt vsepc} substitutes for the usual {\tt sepc}, so
instructions that normally read or modify {\tt sepc} actually access
{\tt vsepc} instead.
When V=0, {\tt vsepc} does not directly affect the behavior of the
machine.

{\tt vsepc} is a \warl\ register that must be able to hold the same set of
values that {\tt sepc} can hold.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{VSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt vsepc} \\
\hline
VSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor exception program counter ({\tt vsepc}).}
\label{vsepcreg}
\end{figure*}

\subsection{Virtual Supervisor Cause Register ({\tt vscause})}

The {\tt vscause} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt scause}, formatted as shown
in Figure~\ref{vscausereg}.
When V=1, {\tt vscause} substitutes for the usual {\tt scause}, so
instructions that normally read or modify {\tt scause} actually access
{\tt vscause} instead.
When V=0, {\tt vscause} does not directly affect the behavior of the
machine.

{\tt vscause} is a \wlrl\ register that must be able to hold the same set of
values that {\tt scause} can hold.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{c@{}U}
\instbit{VSXLEN-1} &
\instbitrange{VSXLEN-2}{0} \\
\hline
\multicolumn{1}{|c|}{Interrupt} &
\multicolumn{1}{c|}{Exception Code (\wlrl)} \\
\hline
1 & VSXLEN-1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor cause register ({\tt vscause}).}
\label{vscausereg}
\end{figure*}

\subsection{Virtual Supervisor Trap Value Register ({\tt vstval})}

The {\tt vstval} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt stval}, formatted as shown
in Figure~\ref{vstvalreg}.
When V=1, {\tt vstval} substitutes for the usual {\tt stval}, so
instructions that normally read or modify {\tt stval} actually access
{\tt vstval} instead.
When V=0, {\tt vstval} does not directly affect the behavior of the
machine.

{\tt vstval} is a \warl\ register that must be able to hold the same set of
values that {\tt stval} can hold.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{VSXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt vstval} \\
\hline
VSXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor trap value register ({\tt vstval}).}
\label{vstvalreg}
\end{figure*}

\subsection{Virtual Supervisor Address Translation and Protection Register ({\tt vsatp})}

The {\tt vsatp} register is a VSXLEN-bit read/write register that is
VS-mode's version of supervisor register {\tt satp}, formatted as shown
in Figure~\ref{rv32vsatpreg} for VSXLEN=32 and Figure~\ref{rv64vsatpreg}
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-stage address translation, the first stage of
two-stage translation for guest virtual addresses (see
Section~\ref{sec:two-stage-translation}).

\begin{figure}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{c@{}E@{}K}
\instbit{31} &
\instbitrange{30}{22} &
\instbitrange{21}{0} \\
\hline
\multicolumn{1}{|c|}{MODE (\warl)} &
\multicolumn{1}{c|}{ASID (\warl)} &
\multicolumn{1}{c|}{PPN  (\warl)} \\
\hline
1 & 9 & 22 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor address translation and protection register {\tt vsatp} when VSXLEN=32.}
\label{rv32vsatpreg}
\end{figure}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}S@{}T@{}U}
\instbitrange{63}{60} &
\instbitrange{59}{44} &
\instbitrange{43}{0} \\
\hline
\multicolumn{1}{|c|}{MODE (\warl)} &
\multicolumn{1}{c|}{ASID (\warl)} &
\multicolumn{1}{c|}{PPN  (\warl)} \\
\hline
4 & 16 & 44 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Virtual supervisor address translation and protection register {\tt vsatp} when VSXLEN=64, for MODE
values Bare, Sv39, Sv48, and Sv57.}
\label{rv64vsatpreg}
\end{figure*}

The {\tt vsatp} register is considered {\em active} for the purposes of the
address-translation algorithm when the effective privilege mode is VS-mode or
VU-mode.  The {\tt vsatp} register is also considered briefly active when
executing a virtual-machine load/store instruction (HLV, HLVX, or HSV), and
hence the address-translation algorithm may be executed speculatively for any
guest virtual address when such an instruction is executed.

\begin{commentary}
Just as with {\tt hgatp}, defining there to be a brief window during which
{\tt vsatp} is active while executing an HLV, HLVX, or HSV instruction allows
the implementation to prefetch PTEs associated with the {\tt vsatp} register.
\end{commentary}

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 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.
For the supervisor physical address that results from address
translation, the supervisor physical memory attributes must grant both
\textit{execute} and \textit{read} permissions.
(The \textit{supervisor physical memory attributes} are the machine's
physical memory attributes as modified by physical memory protection,
Section~\ref{sec:pmp}, for supervisor level.)

The {\tt hgatp} and {\tt vsatp} registers are considered {\em active}
for the purposes of the address-translation algorithm when executing
virtual-machine load/store instructions (HLV, HLVX, or HSV).

\begin{commentary}
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 exception.
\end{commentary}

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

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

\subsection{Hypervisor Memory-Management Fence Instructions}
\label{sec:hfence.vma}

\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 \\
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.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).

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
hart of the VS-level memory-management data structures, when those implicit
reads are for instructions that
\begin{compactitem}
\item
are subsequent to the HFENCE.VVMA, and
\item
execute when {\tt hgatp}.VMID has the same setting as it did when HFENCE.VVMA
executed.
\end{compactitem}
Implicit reads need not be ordered when {\tt hgatp}.VMID is different than at
the time HFENCE.VVMA executed.
If operand {\em rs1}$\neq${\tt x0}, it specifies a single guest virtual
address, and if operand {\em rs2}$\neq${\tt x0}, it specifies a single guest
address-space identifier
(ASID).

\begin{commentary}
An HFENCE.VVMA instruction applies only to a single virtual machine, identified
by the setting of {\tt hgatp}.VMID when HFENCE.VVMA executes.
\end{commentary}

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

\begin{commentary}
Simpler implementations of HFENCE.VVMA can ignore the guest virtual address in
{\em rs1} and the guest ASID value in {\em rs2}, as well as {\tt hgatp}.VMID,
and always perform a global fence for the VS-level memory management of all
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
that follow the HFENCE.GVMA.
If operand {\em rs1}$\neq${\tt x0}, it specifies a single guest physical
address, shifted right by 2~bits, and if operand {\em rs2}$\neq${\tt x0}, it
specifies a single virtual machine identifier (VMID).

\begin{commentary}
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.
\end{commentary}

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

\begin{commentary}
Simpler implementations of HFENCE.GVMA can ignore the guest physical address in
{\em rs1} and the VMID value in {\em rs2} and always perform a global fence for
the guest-physical memory management of all virtual machines, or even a global
fence for all memory-management data structures.
\end{commentary}

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

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

\section{Machine-Level CSRs}

The hypervisor extension augments or modifies machine CSRs {\tt mstatus},
{\tt mstatush}, {\tt mideleg}, {\tt mip}, and {\tt mie}, and
adds CSRs {\tt mtval2} and {\tt mtinst}.

\subsection{Machine Status Registers ({\tt mstatus} and {\tt mstatush})}

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 and GVA not to {\tt mstatus}
but to {\tt mstatush}.
Figure~\ref{hypervisor-mstatush} shows the {\tt mstatush} register when
the hypervisor extension is implemented and MXLEN=32.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{cMccccFFc}
\\
\instbit{MXLEN-1} &
\instbitrange{MXLEN-2}{40} &
\instbit{39} &
\instbit{38} &
\instbit{37} &
\instbit{36} &
\instbitrange{35}{34} &
\instbitrange{33}{32} &
 \\
\hline
\multicolumn{1}{|c|}{SD} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{MPV} &
\multicolumn{1}{c|}{GVA} &
\multicolumn{1}{c|}{MBE} &
\multicolumn{1}{c|}{SBE} &
\multicolumn{1}{c|}{SXL[1:0]} &
\multicolumn{1}{c|}{UXL[1:0]} &
 \\
\hline
1 & MXLEN-41 & 1 & 1 & 1 & 1 & 2 & 2 & \\
\end{tabular}
\begin{tabular}{cEccccccWWc}
\\
&
\instbitrange{31}{23} &
\instbit{22} &
\instbit{21} &
\instbit{20} &
\instbit{19} &
\instbit{18} &
\instbit{17} &
\instbitrange{16}{15} &
\instbitrange{14}{13} &
 \\
\hline
 &
\multicolumn{1}{|c|}{\wpri} &
\multicolumn{1}{c|}{TSR} &
\multicolumn{1}{c|}{TW} &
\multicolumn{1}{c|}{TVM} &
\multicolumn{1}{c|}{MXR} &
\multicolumn{1}{c|}{SUM} &
\multicolumn{1}{c|}{MPRV} &
\multicolumn{1}{c|}{XS[1:0]} &
\multicolumn{1}{c|}{FS[1:0]} &
 \\
\hline
 & 9 & 1 & 1 & 1 & 1 & 1 & 1 & 2 & 2 & \\
\end{tabular}
\begin{tabular}{cFWcccccccccc}
\\
&
\instbitrange{12}{11} &
\instbitrange{10}{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbit{4} &
\instbit{3} &
\instbit{2} &
\instbit{1} &
\instbit{0} \\
\hline
 &
\multicolumn{1}{|c|}{MPP[1:0]} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SPP} &
\multicolumn{1}{c|}{MPIE} &
\multicolumn{1}{c|}{UBE} &
\multicolumn{1}{c|}{SPIE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{MIE} &
\multicolumn{1}{c|}{\wpri} &
\multicolumn{1}{c|}{SIE} &
\multicolumn{1}{c|}{\wpri} \\
\hline
 & 2 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Machine status register ({\tt mstatus}) for RV64 when the hypervisor extension is implemented.}
\label{hypervisor-mstatus}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{LccccF}
\\
\instbitrange{31}{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbit{4} &
\instbitrange{3}{0} \\
\hline
\multicolumn{1}{|c|}{\wpri} &
\multicolumn{1}{c|}{MPV} &
\multicolumn{1}{c|}{GVA} &
\multicolumn{1}{c|}{MBE} &
\multicolumn{1}{c|}{SBE} &
\multicolumn{1}{c|}{\wpri} \\
\hline
24 & 1 & 1 & 1 & 1 & 4 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Additional machine status register ({\tt mstatush}) for RV32 when the hypervisor extension is implemented.
The format of {\tt mstatus} is unchanged for RV32.}
\label{hypervisor-mstatush}
\end{figure*}

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

Field GVA (Guest Virtual Address) is written by the implementation
whenever a trap is taken into M-mode.
For any trap (breakpoint, address misaligned,
access fault, page fault, or guest-page fault) that writes
a guest virtual address to {\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 or HINVAL.GVMA, but has no effect on accesses to {\tt vsatp} or
instructions HFENCE.VVMA or HINVAL.VVMA.

\begin{commentary}
TVM exists in {\tt mstatus} to allow machine-level software to modify
the address translations managed by a supervisor-level OS, usually for
the purpose of inserting another stage of address translation below
that controlled by the OS.
The instruction traps enabled by TVM=1 permit machine level
to co-opt both {\tt satp} and {\tt hgatp} and substitute
\emph{shadow page tables} that merge the OS's chosen page translations
with M-level's lower-stage translations, all without the OS being
aware.
M-level software needs this ability not only to emulate the hypervisor
extension if not already supported, but also to emulate any future
\mbox{RISC-V} extensions that may modify or add address translation
stages, perhaps, for example, to improve support for nested
hypervisors, i.e., running hypervisors atop other hypervisors.

However, setting TVM=1 does not cause traps for accesses to {\tt vsatp}
or instructions HFENCE.VVMA or HINVAL.VVMA, or for any actions taken
in VS-mode, because M-level software is not expected to need to involve
itself in VS-stage address translation.
For virtual machines, it should be sufficient, and in all likelihood
faster as well, to leave VS-stage address translation alone and merge
all other translation stages into G-stage shadow page tables controlled
by {\tt hgatp}.
This assumption does place some constraints on possible future
\mbox{RISC-V} extensions that current machines will be able to emulate
efficiently.
\end{commentary}

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 nominal 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}|}
  \hline
   MPRV & MPV & MPP & Effect \\ \hline \hline
   0    & --  & --  & Normal access; current privilege mode applies. \\ \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    & --  & 3   & M-level access with no translation. \\ \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 MPRV on the translation and protection of explicit
memory accesses.}
\label{h-mprv}
\end{table*}

MPRV does not affect the virtual-machine load/store instructions, HLV,
HLVX, and HSV.
The explicit loads and stores of these instructions always act as though
V=1 and the nominal privilege mode were {\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}.

\FloatBarrier

\subsection{Machine Interrupt Delegation Register ({\tt mideleg})}

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

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

\subsection{Machine Interrupt Registers ({\tt mip} and {\tt mie})}

The hypervisor extension gives registers {\tt mip} and {\tt mie}
additional active bits for the hypervisor-added interrupts.
Figures \ref{hypervisor-mipreg-standard} and
\ref{hypervisor-miereg-standard} show the standard portions (bits 15:0)
of registers {\tt mip} and {\tt mie} when the hypervisor extension is
implemented.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{Yccccccccccccc}
\instbitrange{15}{13} &
\instbit{12} &
\instbit{11} &
\instbit{10} &
\instbit{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbit{4} &
\instbit{3} &
\instbit{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SGEIP} &
\multicolumn{1}{c|}{MEIP} &
\multicolumn{1}{c|}{VSEIP} &
\multicolumn{1}{c|}{SEIP} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{MTIP} &
\multicolumn{1}{c|}{VSTIP} &
\multicolumn{1}{c|}{STIP} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{MSIP} &
\multicolumn{1}{c|}{VSSIP} &
\multicolumn{1}{c|}{SSIP} &
\multicolumn{1}{c|}{0} \\
\hline
3 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt mip}.}
\label{hypervisor-mipreg-standard}
\end{figure*}

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\setlength{\tabcolsep}{4pt}
\begin{tabular}{Yccccccccccccc}
\instbitrange{15}{13} &
\instbit{12} &
\instbit{11} &
\instbit{10} &
\instbit{9} &
\instbit{8} &
\instbit{7} &
\instbit{6} &
\instbit{5} &
\instbit{4} &
\instbit{3} &
\instbit{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{0} &
\multicolumn{1}{c|}{SGEIE} &
\multicolumn{1}{c|}{MEIE} &
\multicolumn{1}{c|}{VSEIE} &
\multicolumn{1}{c|}{SEIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{MTIE} &
\multicolumn{1}{c|}{VSTIE} &
\multicolumn{1}{c|}{STIE} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{MSIE} &
\multicolumn{1}{c|}{VSSIE} &
\multicolumn{1}{c|}{SSIE} &
\multicolumn{1}{c|}{0} \\
\hline
3 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Standard portion (bits 15:0) of {\tt mie}.}
\label{hypervisor-miereg-standard}
\end{figure*}

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}.

\subsection{Machine Second Trap Value Register ({\tt mtval2})}

The {\tt mtval2} register is an MXLEN-bit read/write register formatted
as shown in Figure~\ref{mtval2reg}.
When a trap is taken into M-mode, {\tt mtval2} is written with additional
exception-specific information, alongside {\tt mtval}, to assist software
in handling the trap.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{MXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt mtval2} \\
\hline
MXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Machine second trap value register ({\tt mtval2}).}
\label{mtval2reg}
\end{figure*}

When a guest-page-fault trap is taken into M-mode, {\tt mtval2} is
written with either zero or the guest physical address that faulted,
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.

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, 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
guest physical addresses, if any.

\subsection{Machine Trap Instruction Register ({\tt mtinst})}

The {\tt mtinst} register is an MXLEN-bit read/write register formatted
as shown in Figure~\ref{mtinstreg}.
When a trap is taken into M-mode, {\tt mtinst} is written with a value
that, if nonzero, provides information about the instruction that
trapped, to assist software in handling the trap.
The values that may be written to {\tt mtinst} on a trap are documented
in Section~\ref{sec:tinst-vals}.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}J}
\instbitrange{MXLEN-1}{0} \\
\hline
\multicolumn{1}{|c|}{\tt mtinst} \\
\hline
MXLEN \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Machine trap instruction register ({\tt mtinst}).}
\label{mtinstreg}
\end{figure*}

{\tt mtinst} is a \warl\ register that need only be able to hold the
values that the implementation may automatically write to it on a trap.

\section{Two-Stage Address Translation}
\label{sec:two-stage-translation}

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
by VS-level address translation, as controlled by the {\tt vsatp}
register, into a {\em guest physical address}.
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-stage page protection.
Setting MXR at VS-level does not override guest-physical page protections.
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 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
addresses and is in effect regardless of virtualization mode.

\subsection{Guest Physical Address Translation}
\label{sec:guest-addr-translation}

The mapping of guest physical addresses to supervisor physical addresses is
controlled by CSR {\tt hgatp} (Section~\ref{sec:hgatp}).

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

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

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

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}E@{}O@{}E}
\instbitrange{33}{22} &
\instbitrange{21}{12} &
\instbitrange{11}{0} \\
\hline
\multicolumn{1}{|c|}{VPN[1]} &
\multicolumn{1}{c|}{VPN[0]} &
\multicolumn{1}{c|}{page offset} \\
\hline
12 & 10 & 12 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Sv32x4 virtual address (guest physical address).}
\label{sv32x4va}
\end{figure*}

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

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}E@{}O@{}O@{}O}
\instbitrange{40}{30} &
\instbitrange{29}{21} &
\instbitrange{20}{12} &
\instbitrange{11}{0} \\
\hline
\multicolumn{1}{|c|}{VPN[2]} &
\multicolumn{1}{c|}{VPN[1]} &
\multicolumn{1}{c|}{VPN[0]} &
\multicolumn{1}{c|}{page offset} \\
\hline
11 & 9 & 9 & 12 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Sv39x4 virtual address (guest physical address).}
\label{sv39x4va}
\end{figure*}

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

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}E@{}O@{}O@{}O@{}O}
\instbitrange{49}{39} &
\instbitrange{38}{30} &
\instbitrange{29}{21} &
\instbitrange{20}{12} &
\instbitrange{11}{0} \\
\hline
\multicolumn{1}{|c|}{VPN[3]} &
\multicolumn{1}{c|}{VPN[2]} &
\multicolumn{1}{c|}{VPN[1]} &
\multicolumn{1}{c|}{VPN[0]} &
\multicolumn{1}{c|}{page offset} \\
\hline
11 & 9 & 9 & 9 & 12 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Sv48x4 virtual address (guest physical address).}
\label{sv48x4va}
\end{figure*}

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

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}S@{}R@{}R@{}R@{}R@{}S}
\instbitrange{58}{50} &
\instbitrange{49}{39} &
\instbitrange{38}{30} &
\instbitrange{29}{21} &
\instbitrange{20}{12} &
\instbitrange{11}{0} \\
\hline
\multicolumn{1}{|c|}{VPN[4]} &
\multicolumn{1}{c|}{VPN[3]} &
\multicolumn{1}{c|}{VPN[2]} &
\multicolumn{1}{c|}{VPN[1]} &
\multicolumn{1}{c|}{VPN[0]} &
\multicolumn{1}{c|}{page offset} \\
\hline
11 & 9 & 9 & 9 & 9 & 12 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Sv57x4 virtual address (guest physical address).}
\label{sv57x4va}
\end{figure*}

\begin{commentary}
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.
This may include the possibility of a machine virtualizing itself, if it
happens to use 33-bit or 34-bit physical addresses.
Multiplying the size and alignment of the root page table by a factor of four
is the cheapest way to extend Sv32 to cover a 34-bit address.
The possible wastage of 12~KiB for an unnecessarily large root page table is
expected to be of negligible consequence for most (maybe all) real uses.

A consistent ability to virtualize machines having as much as four times the
physical address space as virtual address space is believed to be of some
utility also for RV64.
For a machine implementing 39-bit virtual addresses (Sv39), for example, this
allows the hypervisor extension to support up to a 41-bit guest physical
address space without either necessitating hardware support for 48-bit virtual
addresses (Sv48) or falling back to emulating the larger address space using
shadow page tables.
\end{commentary}

The conversion of an Sv32x4, Sv39x4, Sv48x4, or Sv57x4 guest physical address is
accomplished with the same algorithm used for Sv32, Sv39, Sv48, or Sv57, as
presented in Section~\ref{sv32algorithm}, except that:
\begin{compactitem}
\item
{\tt hgatp} substitutes for the usual {\tt satp};
\item
for the translation to begin, the effective privilege mode must be VS-mode or
VU-mode;
\item
when checking the U~bit, the current privilege mode is always taken to be
U-mode; and
\item
guest-page-fault exceptions are raised instead of regular page-fault
exceptions.
\end{compactitem}

For G-stage address translation, all memory accesses (including those
made to access data structures for VS-stage address translation) are considered
to be user-level accesses, as though executed in U-mode.
Access type permissions---readable, writable, or executable---are checked
during G-stage translation the same as for VS-stage
translation.
For a memory access made to support VS-stage address translation (such as to
read/write a VS-level page table), permissions 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).

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

\begin{commentary}
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 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}

\subsection{Guest-Page Faults}

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

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

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

\subsection{Memory-Management Fences}

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

When V=1, the virtual-address argument to SFENCE.VMA is a guest virtual
address within the current virtual machine, and the ASID argument is a VS-level
ASID within the current virtual machine.
The current virtual machine is identified by the VMID field of CSR {\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-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.VVMA and HFENCE.GVMA provide additional
memory-management fences to complement SFENCE.VMA.
These instructions are described in Section~\ref{sec:hfence.vma}.

Section~\ref{pmp-vmem} discusses the intersection between physical memory
protection (PMP) and page-based address translation.
It is noted there that, when PMP settings are modified in a manner that affects
either the physical memory that holds page tables or the physical memory to
which page tables point, M-mode software must synchronize the PMP settings with
the virtual memory system.
For HS-level address translation, this is accomplished by executing in M-mode
an SFENCE.VMA instruction with {\em rs1}={\tt x0} and {\em rs2}={\tt x0}, after
the PMP CSRs are written.
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
guest-physical page tables point, an HFENCE.GVMA instruction with
{\em rs1}={\tt x0} and {\em rs2}={\tt x0} must be executed in M-mode after the
PMP CSRs are written.
An HFENCE.VVMA instruction is not required.

\section{Traps}

\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), for virtual
instruction exceptions (exception~22), and for guest-page faults
(exceptions 20, 21,~23).
Furthermore, environment calls from VS-mode are assigned cause 10,
whereas those from HS-mode or S-mode use cause~9 as usual.

\begin{table*}[p]
\begin{center}
\begin{tabular}{|r|r|l|l|}
  \hline
  Interrupt & Exception Code  & Description \\
  \hline
  1         & 0               & {\em Reserved} \\
  1         & 1               & Supervisor software interrupt \\
  1         & 2               & Virtual supervisor software interrupt \\
  1         & 3               & Machine software interrupt \\ \hline
  1         & 4               & {\em Reserved} \\
  1         & 5               & Supervisor timer interrupt \\
  1         & 6               & Virtual supervisor timer interrupt \\
  1         & 7               & Machine timer interrupt \\ \hline
  1         & 8               & {\em Reserved} \\
  1         & 9               & Supervisor external interrupt \\
  1         & 10              & Virtual supervisor external interrupt \\
  1         & 11              & Machine external interrupt \\ \hline
  1         & 12              & Supervisor guest external interrupt \\
  1         & 13--15          & {\em Reserved} \\
  1         & $\ge$16         & {\em Designated for platform or custom use} \\ \hline
  0         & 0               & Instruction address misaligned \\
  0         & 1               & Instruction access fault \\
  0         & 2               & Illegal instruction \\
  0         & 3               & Breakpoint \\
  0         & 4               & Load address misaligned \\
  0         & 5               & Load access fault \\
  0         & 6               & Store/AMO address misaligned \\
  0         & 7               & Store/AMO access fault \\
  0         & 8               & Environment call from U-mode or VU-mode \\
  0         & 9               & Environment call from HS-mode \\
  0         & 10              & Environment call from VS-mode \\
  0         & 11              & Environment call from M-mode \\
  0         & 12              & Instruction page fault \\
  0         & 13              & Load page fault \\
  0         & 14              & {\em Reserved} \\
  0         & 15              & Store/AMO page fault \\
  0         & 16--19          & {\em Reserved} \\
  0         & 20              & Instruction guest-page fault \\
  0         & 21              & Load guest-page fault \\
  0         & 22              & Virtual instruction \\
  0         & 23              & Store/AMO guest-page fault \\
  0         & 24--31          & {\em Designated for custom use} \\
  0         & 32--47          & {\em Reserved} \\
  0         & 48--63          & {\em Designated for custom use} \\
  0         & $\ge$64         & {\em Reserved} \\
  \hline
\end{tabular}
\end{center}
\caption{Machine and supervisor cause register ({\tt mcause} and
{\tt scause}) values when the hypervisor extension is implemented.}
\label{hcauses}
\end{table*}

\begin{commentary}
HS-mode and VS-mode ECALLs use different cause values so they can be delegated
separately.
\end{commentary}

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

Special rules apply for CSR instructions that access \mbox{32-bit}
high-half CSRs such as {\tt cycleh} and {\tt htimedeltah}.
When V=1 and XLEN$>$32, an attempt to access a high-half
supervisor-level CSR, high-half hypervisor CSR, high-half VS CSR,
or high-half unprivileged CSR always raises an illegal instruction
exception.
And in VS-mode, if the XLEN for VU-mode is greater than 32, an attempt
to access a high-half user-level CSR (distinct from an unprivileged
CSR) always raises an illegal instruction exception.
On the other hand, when V=1 and XLEN=32, an invalid attempt to access a
high-half S-level, hypervisor, VS, or unprivileged CSR raises a virtual
instruction exception instead of an illegal instruction exception
if the same CSR instruction for the partner \textit{low-half} CSR
(e.g.\@ {\tt cycle} or {\tt htimedelta}) is HS-qualified.
Likewise, in VS-mode, if the XLEN for VU-mode is 32, an invalid attempt
to access a high-half user-level CSR raises a virtual instruction
exception instead of an illegal instruction exception if the same CSR
instruction for the partner low-half CSR is HS-qualified.

\begin{commentary}
The RISC-V Privileged Architecture currently defines no user-level
CSRs, but they might be added by a future version of this standard or
by an extension.
\end{commentary}

Specifically, a virtual instruction exception is raised for the
following cases:
\begin{itemize}

\item
in VS-mode,
attempts to access a non-high-half counter CSR when the corresponding bit in
{\tt hcounteren} is~0 and the same bit in {\tt mcounteren} is~1;

\item
in VS-mode, if XLEN=32, attempts to access a high-half
counter CSR when the corresponding bit in {\tt hcounteren} is~0 and the
same bit in {\tt mcounteren} is~1;

\item
in VU-mode, attempts to access a non-high-half counter CSR when the
corresponding bit in either {\tt hcounteren} or {\tt scounteren} is~0
and the same bit in {\tt mcounteren} is~1;

\item
in VU-mode, if XLEN=32, attempts to access a high-half counter CSR when
the corresponding bit in either {\tt hcounteren} or {\tt scounteren}
is~0 and the same bit in {\tt mcounteren} is~1;

\item
in VS-mode or VU-mode,
attempts to execute a hypervisor instruction (HLV, HLVX, HSV, or HFENCE);

\item
in VS-mode or VU-mode, attempts to access an implemented non-high-half
hypervisor CSR or VS CSR when the same access (read/write) would be
allowed in HS-mode, assuming {\tt mstatus}.TVM=0;

\item
in VS-mode or VU-mode, if XLEN=32, attempts to access an implemented
high-half hypervisor CSR or high-half VS CSR when the same access
(read/write) to the CSR's low-half partner would be allowed in HS-mode,
assuming {\tt mstatus}.TVM=0;

\item
in VU-mode, attempts to execute WFI when {\tt mstatus}.TW=0, or to
execute a supervisor instruction (SRET or SFENCE);

\item
in VU-mode, attempts to access an implemented non-high-half supervisor
CSR when the same access (read/write) would be allowed in HS-mode,
assuming {\tt mstatus}.TVM=0;

\item
in VU-mode, if XLEN=32, attempts to access an implemented high-half
supervisor CSR when the same access to the CSR's low-half partner would
be allowed in HS-mode, assuming {\tt mstatus}.TVM=0;

\item
in VS-mode, attempts to execute WFI when {\tt hstatus}.VTW=1 and
{\tt mstatus}.TW=0, unless the instruction completes within an
implementation-specific, bounded time;

\item
in VS-mode, attempts to execute SRET when {\tt hstatus}.VTSR=1; and

\item
in VS-mode, attempts to execute an SFENCE.VMA or SINVAL.VMA instruction or to
access {\tt satp}, when {\tt hstatus}.VTVM=1.

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

On a virtual instruction trap, {\tt mtval} or {\tt stval} is written the
same as for an illegal instruction trap.

\begin{commentary}
It is not unusual that hypervisors must emulate the
instructions that raise virtual instruction exceptions, to
support nested hypervisors or for other reasons.
Machine level is expected ordinarily to delegate virtual instruction
traps directly to HS-level, whereas illegal instruction traps are likely
to be processed first in M-mode before being conditionally delegated (by
software) to HS-level.
Consequently, virtual instruction traps are expected typically to be
handled faster than illegal instruction traps.

When not emulating the trapping instruction,
a hypervisor should convert a virtual
instruction trap into an illegal instruction exception for the guest
virtual machine.
\end{commentary}

\begin{commentary}
Because TSR and TVM in {\tt mstatus} are intended to impact only S-mode
(HS-mode), they are ignored for determining exceptions in VS-mode.
\end{commentary}

\begin{table*}[htbp]
\begin{center}
\begin{tabular}{|l|r|l|}
  \hline
  Priority      & Exc.\@ Code  & Description \\
  \hline
  {\em Highest} &            3 & Instruction address breakpoint \\
  \hline
                &              & During instruction address translation: \\
                &    12, 20, 1 & \quad First encountered page fault,
                                   guest-page fault, or access fault \\
  \hline
                &              & With physical address for instruction: \\
                &            1 & \quad Instruction access fault \\
  \hline
                &            2 & Illegal instruction \\
                &           22 & Virtual instruction \\
                &            0 & Instruction address misaligned \\
                & 8, 9, 10, 11 & Environment call \\
                &            3 & Environment break \\
                &            3 & Load/store/AMO address breakpoint \\
  \hline
                &              & Optionally: \\
                &         4, 6 & \quad Load/store/AMO address misaligned \\
  \hline
                &              & During address translation for an explicit
                                   memory access: \\
        & 13, 15, 21, 23, 5, 7 & \quad First encountered page fault,
                                   guest-page fault, or access fault \\
  \hline
                &              & With physical address for an explicit
                                   memory access: \\
                &         5, 7 & \quad Load/store/AMO access fault \\
  \hline
                &              & If not higher priority: \\
  {\em Lowest}  &         4, 6 & \quad Load/store/AMO address misaligned \\
  \hline
\end{tabular}
\end{center}
\caption{%
Synchronous exception priority when the hypervisor extension is
implemented.%
}
\label{tab:HSyncExcPrio}
\end{table*}

If an instruction may raise multiple synchronous exceptions, the
decreasing priority order of Table~\ref{tab:HSyncExcPrio} indicates
which exception is taken and reported in {\tt mcause} or {\tt scause}.

\FloatBarrier

\subsection{Trap Entry}

When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless
delegated by {\tt medeleg} or {\tt mideleg}, in which case it goes to HS-mode.
When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless
delegated by {\tt medeleg} or {\tt mideleg}, in which case it goes to HS-mode,
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 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 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!]
\begin{center}
\begin{tabular}{|l|c|c|}
  \hline
  Previous Mode & MPV & MPP \\ \hline
  U-mode        & 0   & 0   \\
  HS-mode       & 0   & 1   \\
  M-mode        & 0   & 3   \\ \hline
  VU-mode       & 1   & 0   \\
  VS-mode       & 1   & 1   \\ \hline
\end{tabular}
\end{center}
\caption{Value of {\tt mstatus}/{\tt mstatush} fields MPV and MPP after a trap into M-mode.
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 set to~0,
and {\tt hstatus}.SPV and {\tt sstatus}.SPP are
set according to Table~\ref{h-spp}.
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!]
\begin{center}
\begin{tabular}{|l|c|c|}
  \hline
  Previous Mode & SPV & SPP \\ \hline
  U-mode        & 0   & 0   \\
  HS-mode       & 0   & 1   \\ \hline
  VU-mode       & 1   & 0   \\
  VS-mode       & 1   & 1   \\ \hline
\end{tabular}
\end{center}
\caption{Value of {\tt hstatus} field SPV and {\tt sstatus} field SPP after a trap into HS-mode.}
\label{h-spp}
\end{table*}

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 fields SPIE and SIE in
{\tt vsstatus} and writes CSRs {\tt vsepc}, {\tt vscause}, and
{\tt vstval}.

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|l|c|}
  \hline
  Previous Mode & SPP \\ \hline
  VU-mode       & 0   \\
  VS-mode       & 1   \\ \hline
\end{tabular}
\end{center}
\caption{Value of {\tt vsstatus} field SPP after a trap into VS-mode.}
\label{h-vspp}
\end{table*}

\FloatBarrier

\subsection{Transformed Instruction or Pseudoinstruction for {\tt mtinst} or {\tt htinst}}
\label{sec:tinst-vals}

On any trap into M-mode or HS-mode, one of these values is written
automatically into the appropriate trap instruction CSR, {\tt mtinst} or
{\tt htinst}:
\begin{tightlist}
\item
zero;
\item
a transformation of the trapping instruction;
\item
a custom value (allowed only if the trapping instruction is nonstandard);
or
\item
a special pseudoinstruction.
\end{tightlist}
Except when a pseudoinstruction value is required (described later), the
value written to {\tt mtinst} or {\tt htinst} may always be zero,
indicating that the hardware is providing no information in the register
for this particular trap.

\begin{commentary}
The value written to the trap instruction CSR serves two purposes.
The first is to improve the speed of instruction emulation in a trap
handler, partly by allowing the handler to skip loading the trapping
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-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
for hardware yet still provide to a trap handler the information needed
to emulate the instruction.
An implementation may at any time reduce its effort by substituting zero
in place of the transformed instruction.
\end{commentary}

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

\begin{itemize}

\item
Bit~0 is {\tt 1}, and replacing bit~1 with {\tt 1} makes the value into a
valid encoding of a standard instruction.

In this case, the instruction that trapped is the same kind as indicated
by the register value, and the register value is the transformation of
the trapping instruction, as defined later.
For example, if bits 1:0 are binary {\tt 11} and the register value is
the encoding of a standard LW (load word) instruction, then the trapping
instruction is LW, and the register value is the transformation of the
trapping LW instruction.

\item
Bit~0 is {\tt 1}, and replacing bit~1 with {\tt 1} makes the value into
an instruction encoding that is explicitly designated for a custom
instruction (\emph{not} an unused reserved encoding).

This is a \textit{custom value}.
The instruction that trapped is a nonstandard instruction.
The interpretation of a custom value is not otherwise specified by this
standard.

\item
The value is one of the special pseudoinstructions defined later, all of
which have bits 1:0 equal to {\tt 00}.

\end{itemize}

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

\begin{commentary}
To be forward-compatible with future revisions of this standard, software
that interprets a nonzero value from {\tt mtinst} or {\tt htinst} must
fully verify that the value conforms to one of the cases listed above.
For instance, for RV64, discovering that bits 6:0 of {\tt mtinst} are
{\tt 0000011} and bits 14:12 are {\tt 010} is not sufficient to establish
that the first case applies and the trapping instruction is a standard LW
instruction;
rather, software must also confirm that bits 63:32 of {\tt mtinst} are
all zeros.
A future standard might define new values for 64-bit {\tt mtinst} that
are nonzero in bits 63:32 yet may coincidentally have in bits 31:0 the
same bit patterns as standard RV64 instructions.
\end{commentary}

\begin{commentary}
Unlike for standard instructions, there is no requirement that the
instruction encoding of a custom value be of the same ``kind'' as the
instruction that trapped (or even have any correlation with the trapping
instruction).
\end{commentary}

Table~\ref{tab:tinst-values} shows the values that may be automatically
written to the trap instruction register for each standard exception
cause.
For exceptions that prevent the fetching of an instruction, only zero or
a pseudoinstruction value may be written.
A custom value may be automatically written only if the instruction that
traps is nonstandard.
A future standard or extension may permit other values to be written,
chosen from the set of allowed values established earlier.

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|l|c|c|c|c|}
\hline
                               &      & Transformed &        & Pseudo- \\
                               &      & Standard    & Custom & instruction \\
Exception                      & Zero & Instruction & Value  & Value \\
\hline
Instruction address misaligned & Yes  & No          & Yes    & No  \\
\hline
Instruction access fault       & Yes  & No          & No     & No  \\
Illegal instruction            & Yes  & No          & No     & No  \\
Breakpoint                     & Yes  & No          & Yes    & No  \\
Virtual instruction            & Yes  & No          & Yes    & No  \\
\hline
Load address misaligned        & Yes  & Yes         & Yes    & No  \\
Load access fault              & Yes  & Yes         & Yes    & No  \\
Store/AMO address misaligned   & Yes  & Yes         & Yes    & No  \\
Store/AMO access fault         & Yes  & Yes         & Yes    & No  \\
\hline
Environment call               & Yes  & No          & Yes    & No  \\
\hline
Instruction page fault         & Yes  & No          & No     & No  \\
Load page fault                & Yes  & Yes         & Yes    & No  \\
Store/AMO page fault           & Yes  & Yes         & Yes    & No  \\
\hline
Instruction guest-page fault   & Yes  & No          & No     & Yes \\
Load guest-page fault          & Yes  & Yes         & Yes    & Yes \\
Store/AMO guest-page fault     & Yes  & Yes         & Yes    & Yes \\
\hline
\end{tabular}
\end{center}
\caption{Values that may be automatically written to the trap instruction
register ({\tt mtinst} or {\tt htinst}) on an exception trap.}
\label{tab:tinst-values}
\end{table*}

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

\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
Figure~\ref{transformedloadinst}.

\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|}{0} &
\multicolumn{1}{c|}{0} &
\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 noncompressed load instruction (LB, LBU, LH, LHU,
LW, LWU, LD, FLW, FLD, or FLQ).
Fields funct3, rd, and opcode are the same as the trapping load
instruction.}
\label{transformedloadinst}
\end{figure*}

For a standard store instruction that is not a compressed instruction and
is one of SB, SH, SW, SD, FSW, FSD, or FSQ, the transformed instruction
has the format shown in Figure~\ref{transformedstoreinst}.

\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|}{0} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{Addr.\ Offset} &
\multicolumn{1}{c|}{funct3} &
\multicolumn{1}{c|}{0} &
\multicolumn{1}{c|}{opcode} \\
\hline
7 & 5 & 5 & 3 & 5 & 7 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Transformed noncompressed store instruction (SB, SH, SW, SD,
FSW, FSD, or FSQ).
Fields rs2, funct3, and opcode are the same as the trapping store
instruction.}
\label{transformedstoreinst}
\end{figure*}

For a standard atomic instruction (load-reserved, store-conditional, or
AMO instruction), the transformed instruction has the format shown in
Figure~\ref{transformedatomicinst}.

\begin{figure*}[h!]
{\footnotesize
\begin{center}
\begin{tabular}{@{}R@{}c@{}c@{}R@{}R@{}F@{}R@{}S}
\\
\instbitrange{31}{27} &
\instbit{26} &
\instbit{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{aq} &
\multicolumn{1}{c|}{rl} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{Addr.\ Offset} &
\multicolumn{1}{c|}{funct3} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 1 & 1 & 5 & 5 & 3 & 5 & 7 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Transformed atomic instruction (load-reserved,
store-conditional, or AMO instruction).
All fields are the same as the trapping instruction except bits 19:15,
Addr.\ Offset.}
\label{transformedatomicinst}
\end{figure*}

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 a misaligned memory access.
Note also that, for basic loads and stores, the transformations replace
the instruction's immediate offset fields with zero.

For a standard compressed instruction (16-bit size), the transformed
instruction is found as follows:
\begin{enumerate}
\item
Expand the compressed instruction to its 32-bit equivalent.
\item
Transform the 32-bit equivalent instruction.
\item
Replace bit~1 with a~{\tt 0}.
\end{enumerate}
Bits 1:0 of a transformed standard instruction will be binary {\tt 01} if
the trapping instruction is compressed and {\tt 11} if not.

\begin{commentary}
In decoding the contents of {\tt mtinst} or {\tt htinst}, once software
has determined that the register contains the encoding of a standard
basic load (LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, or FLQ) or basic
store (SB, SH, SW, SD, FSW, FSD, or FSQ), it is not necessary to confirm
also that the immediate offset fields (31:25, and 24:20 or 11:7) are
zeros.
The knowledge that the register's value is the encoding of a basic
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
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 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}.
If both conditions are met, the value written to {\tt mtinst} or
{\tt htinst} must be taken from Table~\ref{tab:pseudoinsts};
zero is not allowed.

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|l|l|}
\hline
Value            & Meaning \\
\hline
{\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-stage address translation (RV64) \\
{\tt 0x00003020} & 64-bit write for VS-stage address translation (RV64) \\
\hline
\end{tabular}
\end{center}
\caption{Special pseudoinstruction values for guest-page faults.
The RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64.}
\label{tab:pseudoinsts}
\end{table*}

The defined pseudoinstruction values are designed to correspond closely
with the encodings of basic loads and stores, as illustrated by
Table~\ref{tab:pseudoinsts-basis}.

\begin{table*}[h!]
\begin{center}
\begin{tabular}{|l|l|}
\hline
Encoding         & Instruction \\ \hline
{\tt 0x00002003} & {\tt lw x0,0(x0)} \\
{\tt 0x00002023} & {\tt sw x0,0(x0)} \\ \hline
{\tt 0x00003003} & {\tt ld x0,0(x0)} \\
{\tt 0x00003023} & {\tt sd x0,0(x0)} \\ \hline
\end{tabular}
\end{center}
\caption{Standard instructions corresponding to the special
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-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
arise.
The fact that such a page table update must actually be atomic, not just
a simple write, is ignored for the pseudoinstruction.

\begin{commentary}
If the conditions that necessitate a pseudoinstruction value can ever
occur for M-mode, then {\tt mtinst} cannot be entirely read-only zero;
and likewise for HS-mode and {\tt htinst}.
However, in that case, the trap instruction registers may minimally
support only values 0 and {\tt 0x00002000} or {\tt 0x00003000}, and
possibly {\tt 0x00002020} or {\tt 0x00003020}, requiring as few as one or
two flip-flops in hardware, per register.
\end{commentary}

\begin{commentary}
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
missing page of virtual memory) before resuming execution by retrying the
faulting instruction.
\end{commentary}

\subsection{Trap Return}

The MRET instruction is used to return from a trap taken into M-mode.
MRET first determines what the new privilege mode will be according to
the values of MPP and MPV in {\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.
Lastly, MRET sets the privilege mode as previously
determined, and sets {\tt pc}={\tt mepc}.

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

When executed in M-mode or HS-mode (i.e., V=0), SRET first determines
what the new privilege mode will be according to the values in
{\tt hstatus}.SPV and {\tt sstatus}.SPP, as encoded in Table~\ref{h-spp}.
SRET then sets {\tt hstatus}.SPV=0, and in {\tt sstatus} sets SPP=0,
SIE=SPIE, and SPIE=1.
Lastly, SRET sets the privilege mode 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}, in {\tt vsstatus} sets SPP=0, SIE=SPIE, and SPIE=1, and
lastly sets {\tt pc}={\tt vsepc}.