[[supervisor]]
== Supervisor-Level ISA, Version 1.13

This chapter describes the RISC-V supervisor-level architecture, which
contains a common core that is used with various supervisor-level
address translation and protection schemes.

[NOTE]
====
Supervisor mode is deliberately restricted in terms of interactions with
underlying physical hardware, such as physical memory and device
interrupts, to support clean virtualization. In this spirit, certain
supervisor-level facilities, including requests for timer and
interprocessor interrupts, are provided by implementation-specific
mechanisms. In some systems, a supervisor execution environment (SEE)
provides these facilities in a manner specified by a supervisor binary
interface (SBI). Other systems supply these facilities directly, through
some other implementation-defined mechanism.
====

=== Supervisor CSRs

A number of CSRs are provided for the supervisor.

[NOTE]
====
The supervisor should only view CSR state that should be visible to a
supervisor-level operating system. In particular, there is no
information about the existence (or non-existence) of higher privilege
levels (machine level or other) visible in the CSRs accessible by the
supervisor.

Many supervisor CSRs are a subset of the equivalent machine-mode CSR,
and the machine-mode chapter should be read first to help understand the
supervisor-level CSR descriptions.
====

[[sstatus]]
==== Supervisor Status (`sstatus`) Register

[[norm:sstatus]]
The `sstatus` register is an SXLEN-bit read/write register formatted as
shown in <<sstatusreg-rv32>> when SXLEN=32
and <<sstatusreg>> when SXLEN=64. The `sstatus`
register keeps track of the processor's current operating state.

[[sstatusreg-rv32]]
.Supervisor-mode status (`sstatus`) register when SXLEN=32.
[wavedrom, ,svg]
....
{reg: [
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SIE'},
  {bits:  3, name: 'WPRI'},
  {bits:  1, name: 'SPIE'},
  {bits:  1, name: 'UBE'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SPP'},
  {bits:  2, name: 'VS[1:0]'},
  {bits:  2, name: 'WPRI'},
  {bits:  2, name: 'FS[1:0]'},
  {bits:  2, name: 'XS[1:0]'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SUM'},
  {bits:  1, name: 'MXR'},
  {bits:  3, name: 'WPRI'},
  {bits:  1, name: 'SPELP'},
  {bits:  1, name: 'SDT'},
  {bits:  6, name: 'WPRI'},
  {bits:  1, name: 'SD'},
], config:{lanes: 2, hspace:1024}}
....

[[sstatusreg]]
.Supervisor-mode status (`sstatus`) register when SXLEN=64.
[wavedrom, ,svg]
....
{reg: [
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SIE'},
  {bits:  3, name: 'WPRI'},
  {bits:  1, name: 'SPIE'},
  {bits:  1, name: 'UBE'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SPP'},
  {bits:  2, name: 'VS[1:0]'},
  {bits:  2, name: 'WPRI'},
  {bits:  2, name: 'FS[1:0]'},
  {bits:  2, name: 'XS[1:0]'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'SUM'},
  {bits:  1, name: 'MXR'},
  {bits:  3, name: 'WPRI'},
  {bits:  1, name: 'SPELP'},
  {bits:  1, name: 'SDT'},
  {bits:  7, name: 'WPRI'},
  {bits:  2, name: 'UXL[1:0]'},
  {bits: 29, name: 'WPRI'},
  {bits:  1, name: 'SD'},
], config:{lanes: 4, hspace:1024}}
....

[[norm:sstatus_spp]]
The SPP bit indicates the privilege level at which a hart was executing
before entering supervisor mode. When a trap is taken, SPP is set to 0
if the trap originated from user mode, or 1 otherwise. When an SRET
instruction (see <<otherpriv>>) is executed to
return from the trap handler, the privilege level is set to user mode if
the SPP bit is 0, or supervisor mode if the SPP bit is 1; SPP is then
set to 0.

[[norm:sstatus_sie]]
The SIE bit enables or disables all interrupts in supervisor mode. When
SIE is clear, interrupts are not taken while in supervisor mode. When
the hart is running in user-mode, the value in SIE is ignored, and
supervisor-level interrupts are enabled. The supervisor can disable
individual interrupt sources using the `sie` CSR.

[[norm:sstatus_spie]]
The SPIE bit indicates whether supervisor interrupts were enabled prior
to trapping into supervisor mode. When a trap is taken into supervisor
mode, SPIE is set to SIE, and SIE is set to 0. When an SRET instruction
is executed, SIE is set to SPIE, then SPIE is set to 1.

The `sstatus` register is a subset of the `mstatus` register.

[NOTE]
====
In a straightforward implementation, reading or writing any field in
`sstatus` is equivalent to reading or writing the homonymous field in
`mstatus`.
====

===== Base ISA Control in `sstatus` Register

[[norm:sstatus_uxl]]
The UXL field controls the value of XLEN for U-mode, termed _UXLEN_,
which may differ from the value of XLEN for S-mode, termed _SXLEN_. The
encoding of UXL is the same as that of the MXL field of `misa`, shown in
<<norm:misa_mxl_enc>>.

[[norm:sstatus_uxl_sz]]
When SXLEN=32, the UXL field does not exist, and UXLEN=32. When
SXLEN=64, it is a *WARL* field that encodes the current value of UXLEN. In
particular, an implementation may make UXL be a read-only field whose
value always ensures that UXLEN=SXLEN.

[[norm:sstatus_uxl_behavior]]
If UXLEN≠SXLEN, instructions executed in the narrower
mode must ignore source register operand bits above the configured XLEN,
and must sign-extend results to fill the widest supported XLEN in the
destination register.

If UXLEN < SXLEN, user-mode instruction-fetch addresses
and load and store effective addresses are taken modulo
2^UXLEN^. For example, when UXLEN=32 and SXLEN=64,
user-mode memory accesses reference the lowest 4 GiB of the address space.

[[norm:hint_sxlen]]
Some HINT instructions are encoded as integer computational instructions that
overwrite their destination register with its current value, e.g.,
`c.addi x8, 0`.
When such a HINT is executed with XLEN < SXLEN and bits SXLEN..XLEN of the
destination register not all equal to bit XLEN-1, it is implementation-defined
whether bits SXLEN..XLEN of the destination register are unchanged or are
overwritten with copies of bit XLEN-1.

NOTE: This definition allows implementations to elide register write-back for
some HINTs, while allowing them to execute other HINTs in the same manner as
other integer computational instructions.
The implementation choice is observable only by S-mode with SXLEN > UXLEN; it
is invisible to U-mode.

[[sum]]
===== Memory Privilege in `sstatus` Register

[[norm:sstatus_mxr]]
The MXR (Make eXecutable Readable) bit modifies the privilege with which
loads access virtual memory. When MXR=0, only loads from pages marked
readable (R=1 in <<sv32pte>>) will succeed. When
MXR=1, loads from pages marked either readable or executable (R=1 or
X=1) will succeed. MXR has no effect when page-based virtual memory is
not in effect.

[[norm:sstatus_sum]]
The SUM (permit Supervisor User Memory access) bit modifies the
privilege with which S-mode loads and stores access virtual memory. When
SUM=0, S-mode memory accesses to pages that are accessible by U-mode
(U=1 in <<sv32pte>>) will fault. When SUM=1, these
accesses are permitted. SUM has no effect when page-based virtual memory
is not in effect, nor when executing in U-mode. Note that S-mode can
never execute instructions from user pages, regardless of the state of
SUM.

[[norm:sstatus_sum_satp_mode]]
SUM is read-only 0 if `satp`.MODE is read-only 0.

[NOTE]
====
The SUM mechanism prevents supervisor software from inadvertently
accessing user memory. Operating systems can execute the majority of
code with SUM clear; the few code segments that should access user
memory can temporarily set SUM.

The SUM mechanism does not avail S-mode software of permission to
execute instructions in user code pages. Legitimate use cases for
execution from user memory in supervisor context are rare in general and
nonexistent in POSIX environments. However, bugs in supervisors that
lead to arbitrary code execution are much easier to exploit if the
supervisor exploit code can be stored in a user buffer at a virtual
address chosen by an attacker.

Some non-POSIX single address space operating systems do allow certain
privileged software to partially execute in supervisor mode, while most
programs run in user mode, all in a shared address space. This use case
can be realized by mapping the physical code pages at multiple virtual
addresses with different permissions, possibly with the assistance of
the instruction page-fault handler to direct supervisor software to use
the alternate mapping.
====

===== Endianness Control in `sstatus` Register

[[norm:sstatus_ube]]
The UBE bit is a *WARL* field that controls the endianness of explicit memory
accesses made from U-mode, which may differ from the endianness of
memory accesses in S-mode. An implementation may make UBE be a read-only
field that always specifies the same endianness as for S-mode.

UBE controls whether explicit load and store memory accesses made from
U-mode are little-endian (UBE=0) or big-endian (UBE=1).

[[norm:sstatus_ube_implicit]]
UBE has no effect on instruction fetches, which are _implicit_ memory
accesses that are always little-endian.

For _implicit_ accesses to supervisor-level memory management data
structures, such as page tables, S-mode endianness always applies and
UBE is ignored.

[NOTE]
====
Standard RISC-V ABIs are expected to be purely little-endian-only or
big-endian-only, with no accommodation for mixing endianness.
Nevertheless, endianness control has been defined so as to permit an OS
of one endianness to execute user-mode programs of the opposite
endianness.
====

===== Previous Expected Landing Pad (ELP) State in `sstatus` Register

[[norm:sstatus_spelp]]
Access to the `SPELP` field, added by Zicfilp, accesses the homonymous
fields of `mstatus` when `V=0`, and the homonymous fields of `vsstatus`
when `V=1`.

[[supv-double-trap]]
===== Double Trap Control in `sstatus` Register

[[norm:sstatus_sdt]]
The S-mode-disable-trap (`SDT`) bit is a WARL field introduced by the Ssdbltrp
extension to address double trap (See <<machine-double-trap>>) at privilege
modes lower than M.

[[norm:sstatus_sdt_sstatus_sie_overwrite]]
When the `SDT` bit is set to 1 by an explicit CSR write, the `SIE` (Supervisor
Interrupt Enable) bit is cleared to 0. This clearing occurs regardless of the
value written, if any, to the `SIE` bit by the same write. The `SIE` bit can
only be set to 1 by an explicit CSR write if the `SDT` bit is being set to 0 by
the same write or is already 0.

[[norm:sstatus_sdt_trap]]
When a trap is to be taken into S-mode, if the `SDT` bit is currently 0,
it is then set to 1, and the trap is delivered as expected. However, if `SDT` is
already set to 1, then this is an _unexpected trap_. In the event of an
_unexpected trap_, a double-trap exception trap is delivered into M-mode. To
deliver this trap, the hart writes registers, except `mcause` and `mtval2`, with
the same information that the _unexpected trap_ would have written if it was
taken into M-mode. The `mtval2` register is then set to what would be otherwise
written into the `mcause` register by the _unexpected trap_. The `mcause`
register is set to 16, the double-trap exception code.

[[norm:sstatus_sdt_sret]]
An `SRET` instruction sets the `SDT` bit to 0.

[NOTE]
====
After a trap handler has saved the state, such as `scause`, `sepc`,
and `stval`, needed for resuming from the trap and is reentrant, it
should clear the `SDT` bit.

Resetting the `SDT` by an `SRET` enables the trap handler to detect a double
trap that may occur during the tail phase, where it restores critical state
to return from a trap.

The consequence of this specification is that if a critical error condition was
caused by a guest-page fault, then the GPA will not be available in `mtval2`
when the double trap is delivered to M-mode. This condition arises if the
HS-mode invokes a hypervisor virtual-machine load or store instruction when
`SDT` is 1 and the instruction raises a guest-page fault. The use of such an
instruction in this phase of trap handling is not common. However, not recording
the GPA is considered benign because, if required, it can still be obtained
-- albeit with added effort -- through the process of walking the page tables.

For a double trap that originates in VS-mode, M-mode should redirect the exception
to HS-mode by copying the values of M-mode CSRs updated by the trap to HS-mode
CSRs and should use an `MRET` to resume execution at the address in `stvec`.

Supervisor Software Events (SSE), an extension to the SBI, provide a
mechanism for supervisor software to register and service system events
emanating from an SBI implementation, such as firmware or a hypervisor. In the
event of a double trap, HS-mode and M-mode can utilize the SSE mechanism to
invoke a critical-error handler in VS-mode or S/HS-mode, respectively.
Additionally, the implementation of an SSE protocol can be considered as an
optional measure to aid in the recovery from such critical errors.
====

==== Supervisor Trap Vector Base Address (`stvec`)  Register

[[norm:stvec]]
The `stvec` register is an SXLEN-bit read/write register that holds trap
vector configuration, consisting of a vector base address (BASE) and a
vector mode (MODE).

[[norm:stvec_img]]
.Supervisor trap vector base address (`stvec`) register.
include::images/bytefield/stvec.edn[]

[[norm:stvec_op]]
The BASE field in `stvec` is a *WARL* field that can hold any valid virtual or
physical address, subject to the following alignment constraints: the
address must be 4-byte aligned, and MODE settings other than Direct
might impose additional alignment constraints on the value in the BASE
field.
[[norm:stvec_sz_base]]
Note that the CSR contains only bits XLEN-1 through 2 of the address BASE.
When used as an address, the lower two bits are filled with zeroes to obtain
an XLEN-bit address that is always aligned on a 4-byte boundary.

[[stvec-mode]]
.Encoding of `stvec` MODE field.
[%autowidth,float="center",align="center",cols=">,^,<",options="header",]
|===
|Value |Name |Description
|0 +
1 +
{ge}2
|Direct +
Vectored
|All exceptions set `pc` to BASE. +
Asynchronous interrupts set `pc` to BASE+4{times}cause. +
_Reserved_
|===

The encoding of the MODE field is shown in
<<stvec-mode>>. When MODE=Direct, all traps into
supervisor mode cause the `pc` to be set to the address in the BASE
field. When MODE=Vectored, all synchronous exceptions into supervisor
mode cause the `pc` to be set to the address in the BASE field, whereas
interrupts cause the `pc` to be set to the address in the BASE field
plus four times the interrupt cause number. For example, a
supervisor-mode timer interrupt (see <<scauses>>)
causes the `pc` to be set to BASE+`0x14`. Setting MODE=Vectored may
impose a stricter alignment constraint on BASE.

==== Supervisor Interrupt (`sip` and `sie`) Registers

[[norm:sip_sie]]
The `sip` register is an SXLEN-bit read/write register containing
information on pending interrupts, while `sie` is the corresponding
SXLEN-bit read/write register containing interrupt enable bits.
Interrupt cause number _i_ (as reported in CSR `scause`,
<<scause>>) corresponds with bit _i_ in both `sip` and
`sie`. Bits 15:0 are allocated to standard interrupt causes only, while
bits 16 and above are designated for platform use.

.Supervisor interrupt-pending register (`sip`).
include::images/bytefield/sip.edn[]

.Supervisor interrupt-enable register (`sie`).
include::images/bytefield/sie.edn[]

[[norm:sie_sip_supervisor_strap]]
An interrupt _i_ will trap to S-mode if both of the following are true:
(a) either the current privilege mode is S and the SIE bit in the
`sstatus` register is set, or the current privilege mode has less
privilege than S-mode; and (b) bit _i_ is set in both `sip` and `sie`.

[[norm:sie_sip_strap_time_constraint]]
These conditions for an interrupt trap to occur must be evaluated in a
bounded amount of time from when an interrupt becomes, or ceases to be,
pending in `sip`, and must also be evaluated immediately following the
execution of an SRET instruction or an explicit write to a CSR on which
these interrupt trap conditions expressly depend (including `sip`, `sie`
and `sstatus`).

[[norm:s_interrupt_priority]]
Interrupts to S-mode take priority over any interrupts to lower
privilege modes.

[#norm:sip_acc]#Each individual bit in register `sip` may be writable or may be
read-only.# [#norm:sip_op]#When bit _i_ in `sip` is writable, a pending interrupt _i_
can be cleared by writing 0 to this bit. If interrupt _i_ can become
pending but bit _i_ in `sip` is read-only, the implementation must
provide some other mechanism for clearing the pending interrupt (which
may involve a call to the execution environment).#

[#norm:sie_acc]#A bit in `sie` must be writable if the corresponding interrupt can ever
become pending. Bits of `sie` that are not writable are read-only zero.#

[[norm:sip_sie_bits_sz]]
The standard portions (bits 15:0) of registers `sip` and `sie` are
formatted as shown in Figures <<sipreg-standard>>
and <<siereg-standard>> respectively.

[[sipreg-standard]]
.Standard portion (bits 15:0) of `sip`.
include::images/bytefield/sipreg-standard.edn[]

[[siereg-standard]]
.Standard portion (bits 15:0) of `sie`.
include::images/bytefield/siereg-standard.edn[]


[[norm:sip_seip_sie_seie]]
Bits `sip`.SEIP and `sie`.SEIE are the interrupt-pending and
interrupt-enable bits for supervisor-level external interrupts. If
implemented, SEIP is read-only in `sip`, and is set and cleared by the
execution environment, typically through a platform-specific interrupt
controller.

[[norm:sip_stip_sie_stie]]
Bits `sip`.STIP and `sie`.STIE are the interrupt-pending and interrupt-enable
bits for supervisor-level timer interrupts. If implemented, STIP is read-only in
`sip`. When the Sstc extension is not implemented, STIP is set and cleared by
the execution environment. When the Sstc extension is implemented, STIP reflects
the timer interrupt signal resulting from `stimecmp`. The `sip`.STIP bit, in
response to timer interrupts generated by `stimecmp`, is set by writing
`stimecmp` with a value that is less than or equal to `time`, and is cleared by
writing `stimecmp` with a value greater than `time`.

[[norm:sip_ssip_sie_ssie]]
Bits `sip`.SSIP and `sie`.SSIE are the interrupt-pending and
interrupt-enable bits for supervisor-level software interrupts. If
implemented, SSIP is writable in `sip` and may also be set to 1 by a
platform-specific interrupt controller.

[[norm:sip_sie_Sscofpmf]]
If the Sscofpmf extension is implemented, bits `sip`.LCOFIP and `sie`.LCOFIE
are the interrupt-pending and interrupt-enable bits for local-counter-overflow
interrupts.
LCOFIP is read-write in `sip` and reflects the occurrence of a local
counter-overflow overflow interrupt request resulting from any of the
`mhpmevent__n__`.OF bits being set.
If the Sscofpmf extension is not implemented, `sip`.LCOFIP and `sie`.LCOFIE are
read-only zeros.

[NOTE]
====
Interprocessor interrupts are sent to other harts by
implementation-specific means, which will ultimately cause the SSIP bit
to be set in the recipient hart’s `sip` register.
====

[#norm:std_super_intr_impl]#Each standard interrupt type (SEI, STI, SSI, or LCOFI) may not be implemented,
in which case the corresponding interrupt-pending and interrupt-enable
bits are read-only zeros.#
[#norm:sip_sie_warl]#All bits in `sip` and `sie` are *WARL* fields. The
implemented interrupts may be found by writing one to every bit location
in `sie`, then reading back to see which bit positions hold a one.#

[NOTE]
====
The `sip` and `sie` registers are subsets of the `mip` and `mie`
registers. Reading any implemented field, or writing any writable field,
of `sip`/`sie` effects a read or write of the homonymous field of
`mip`/`mie`.

Bits 3, 7, and 11 of `sip` and `sie` correspond to the machine-mode
software, timer, and external interrupts, respectively. Since most
platforms will choose not to make these interrupts delegatable from
M-mode to S-mode, they are shown as 0 in
<<sipreg-standard>> and <<siereg-standard>>.
====

[[norm:sip_sie_priority_bit_order]]
Multiple simultaneous interrupts destined for supervisor mode are
handled in the following decreasing priority order: SEI, SSI, STI, LCOFI.

==== Supervisor Timers and Performance Counters

Supervisor software uses the same hardware performance monitoring
facility as user-mode software, including the `time`, `cycle`, and
`instret` CSRs. The implementation should provide a mechanism to modify
the counter values.

[[norm:supervisor_timer_scheduling]]
The implementation must provide a facility for scheduling timer
interrupts in terms of the real-time counter, `time`.

==== Counter-Enable (`scounteren`) Register

.Counter-enable (`scounteren`) register
include::images/bytefield/scounteren.edn[]

[[norm:scounteren]]
The counter-enable (`scounteren`) CSR is a 32-bit register that
controls the availability of the hardware performance monitoring
counters to U-mode.

[[norm:scounteren_op]]
When the CY, TM, IR, or HPM__n__ bit in the `scounteren` register is
clear, attempts to read the `cycle`, `time`, `instret`, or `hpmcountern`
register while executing in U-mode will cause an illegal-instruction
exception. When one of these bits is set, access to the corresponding
register is permitted.

[[norm:scounteren_acc]]
`scounteren` must be implemented. However, any of the bits may be
read-only zero, indicating reads to the corresponding counter will cause
an exception when executing in U-mode. Hence, they are effectively
*WARL* fields.

[NOTE]
====
The setting of a bit in `mcounteren` does not affect whether the
corresponding bit in `scounteren` is writable. However, U-mode may only
access a counter if the corresponding bits in `scounteren` and
`mcounteren` are both set.
====

==== Supervisor Scratch (`sscratch`) Register

[[norm:sscratch]]
The `sscratch` CSR is an SXLEN-bit read/write register, dedicated
for use by the supervisor. Typically, `sscratch` is used to hold a
pointer to the hart-local supervisor context while the hart is executing
user code.
At the beginning of a trap handler, software normally uses a CSRRW
instruction to swap `sscratch` with an integer register to obtain an
initial working register.

.Supervisor Scratch Register
include::images/bytefield/sscratch.edn[]

==== Supervisor Exception Program Counter (`sepc`) Register

[[norm:sepc]]
`sepc` is an SXLEN-bit read/write CSR formatted as shown in
<<epcreg>>. The low bit of `sepc` (`sepc[0]`) is always zero. On implementations that support only IALIGN=32, the two low bits (`sepc[1:0]`) are always zero.

[[norm:sepc_op_mask_ialign32]]
If an implementation allows IALIGN to be either 16 or 32 (by changing
CSR `misa`, for example), then, whenever IALIGN=32, bit `sepc[1]` is
masked on reads so that it appears to be 0. This masking occurs also for
the implicit read by the SRET instruction. Though masked, `sepc[1]`
remains writable when IALIGN=32.

[[norm:sepc_acc_invalid_addr]]
`sepc` is a *WARL* register that must be able to hold all valid virtual
addresses. It need not be capable of holding all possible invalid
addresses. Prior to writing `sepc`, implementations may convert an
invalid address into some other invalid address that `sepc` is capable
of holding.

[[norm:sepc_op_trap_write]]
When a trap is taken into S-mode, `sepc` is written with the virtual
address of the instruction that was interrupted or that encountered the
exception. Otherwise, `sepc` is never written by the implementation,
though it may be explicitly written by software.

[[epcreg]]
.Supervisor exception program counter register.
include::images/bytefield/epcreg.edn[]

[[scause]]
==== Supervisor Cause (`scause`) Register

[[norm:scause]]
The `scause` CSR is an SXLEN-bit read-write register formatted as
shown in <<scausereg>>. When a trap is taken into
S-mode, `scause` is written with a code indicating the event that
caused the trap. Otherwise, `scause` is never written by the
implementation, though it may be explicitly written by software.

[[norm:scause_interrupt]]
The Interrupt bit in the `scause` register is set if the trap was caused
by an interrupt. The Exception Code field contains a code identifying
the last exception or interrupt. <<scauses>> lists
the possible exception codes for the current supervisor ISAs. [#norm:scause_exception_code_acc]#The
Exception Code is a *WLRL* field.# [#norm:scause_exception_code_sz]#It is required to hold the values 0–31
(i.e., bits 4–0 must be implemented), but otherwise it is only
guaranteed to hold supported exception codes.#

[[scausereg]]
.Supervisor Cause (`scause`) register.
include::images/bytefield/scausereg.edn[]

[[scauses]]
.Supervisor cause (`scause`) register values after trap. Synchronous exception priorities are given by <<norm:exc_priority>>.
[%autowidth,float="center",align="center",cols=">,>,3",options="header"]
|===
|Interrupt |Exception Code |Description
|1 +
1 +
1 +
1 +
1 +
1 +
1 +
1 +
1 +
1
|0 +
1 +
2-4 +
5 +
6-8 +
9 +
10-12 +
13 +
14-15 +
{ge}16
|_Reserved_ +
Supervisor software interrupt +
_Reserved_ +
Supervisor timer interrupt +
_Reserved_ +
Supervisor external interrupt +
_Reserved_ +
Counter-overflow interrupt +
_Reserved_ +
_Designated for platform use_

|0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0 +
0
|0 +
1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10-11 +
12 +
13 +
14 +
15 +
16-17 +
18 +
19 +
20-23 +
24-31 +
32-47 +
48-63 +
{ge}64
|Instruction address misaligned +
Instruction access fault +
Illegal instruction +
Breakpoint +
Load address misaligned +
Load access fault +
Store/AMO address misaligned +
Store/AMO access fault +
Environment call from U-mode +
Environment call from S-mode +
_Reserved_ +
Instruction page fault +
Load page fault +
_Reserved_ +
Store/AMO page fault +
_Reserved_ +
Software check +
Hardware error +
_Reserved_ +
_Designated for custom use_ +
_Reserved_ +
_Designated for custom use_ +
_Reserved_
|===

==== Supervisor Trap Value (`stval`) Register

[[norm:stval]]
The `stval` CSR is an SXLEN-bit read-write register formatted as
shown in <<stvalreg>>. When a trap is taken into
S-mode, `stval` is written with exception-specific information to assist
software in handling the trap. Otherwise, `stval` is never written by
the implementation, though it may be explicitly written by software. The
hardware platform will specify which exceptions must set `stval`
informatively, which may unconditionally set it to zero, and which may
exhibit either behavior, depending on the underlying event that caused the
exception.

[[norm:stval_op_faulting_addr]]
If `stval` is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, page-fault, or hardware-error exception
occurs on an
instruction fetch, load, or store, then `stval` will contain the
faulting virtual address.

[[norm:stval_op_breakpoint]]
On a breakpoint exception raised by an EBREAK or C.EBREAK instruction, `stval`
is written with either zero or the virtual address of the instruction.

[[stvalreg]]
.Supervisor Trap Value register.
include::images/bytefield/stvalreg.edn[]

[[norm:stval_op_load_store_fault]]
If `stval` is written with a nonzero value when a misaligned load or
store causes an access-fault, page-fault, or hardware-error exception,
then `stval` will
contain the virtual address of the portion of the access that caused the
fault.

[[norm:stval_faulting_address_variable_instr]]
If `stval` is written with a nonzero value when an instruction
access-fault, page-fault, or hardware-error exception occurs on a hart with
variable-length instructions, then `stval` will contain the virtual
address of the portion of the instruction that caused the fault, while
`sepc` will point to the beginning of the instruction.

[[norm:stval_op_illegal_instr]]
The `stval` register can optionally also be used to return the faulting
instruction bits on an illegal-instruction exception (`sepc` points to
the faulting instruction in memory). If `stval` is written with a
nonzero value when an illegal-instruction exception occurs, then `stval`
will contain the shortest of:

* the actual faulting instruction
* the first ILEN bits of the faulting instruction
* the first SXLEN bits of the faulting instruction

[[norm:stval_op_illegal_instr_format]]
The value loaded into `stval` on an illegal-instruction exception is
right-justified and all unused upper bits are cleared to zero.

[[norm:stval_exception_info]]
On a trap caused by a software-check exception, the `stval` register holds the
cause for the exception. The following encodings are defined:

* 0 - No information provided.
* 2 - Landing Pad Fault. Defined by the Zicfilp extension (<<priv-forward>>).
* 3 - Shadow Stack Fault. Defined by the Zicfiss extension (<<priv-backward>>).

[[norm:stval_op_other_traps]]
For other traps, `stval` is set to zero, but a future standard may
redefine `stval`’s setting for other traps.

[[norm:stval_acc]]
`stval` is a *WARL* register that must be able to hold all valid virtual
addresses and the value 0. It need not be capable of holding all
possible invalid addresses. Prior to writing `stval`, implementations
may convert an invalid address into some other invalid address that
`stval` is capable of holding. If the feature to return the faulting
instruction bits is implemented, `stval` must also be able to hold all
values less than 2^_N_^, where _N_ is the smaller
of SXLEN and ILEN.

[[sec:senvcfg]]
==== Supervisor Environment Configuration (`senvcfg`) Register

[[norm:senvcfg]]
The `senvcfg` CSR is an SXLEN-bit read/write register, formatted as
shown in <<senvcfg>>, that controls certain
characteristics of the U-mode execution environment.

[[senvcfg]]
.Supervisor environment configuration register (`senvcfg`) for RV64.
[wavedrom, ,svg]
....
{reg: [
  {bits:  1, name: 'FIOM'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'LPE'},
  {bits:  1, name: 'SSE'},
  {bits:  2, name: 'CBIE'},
  {bits:  1, name: 'CBCFE'},
  {bits:  1, name: 'CBZE'},
  {bits: 24, name: 'WPRI'},
  {bits:  2, name: 'PMM'},
  {bits: 30, name: 'WPRI'},
], config:{lanes: 4, hspace:1024}}
....

.Supervisor environment configuration register (`senvcfg`) for RV32.
[wavedrom, ,svg]
....
{reg: [
  {bits:  1, name: 'FIOM'},
  {bits:  1, name: 'WPRI'},
  {bits:  1, name: 'LPE'},
  {bits:  1, name: 'SSE'},
  {bits:  2, name: 'CBIE'},
  {bits:  1, name: 'CBCFE'},
  {bits:  1, name: 'CBZE'},
  {bits: 24, name: 'WPRI'},
], config:{lanes: 2, hspace:1024}}
....

[[norm:senvcfg_fiom]]
If bit FIOM (Fence of I/O implies Memory) is set to one in `senvcfg`,
FENCE instructions executed in U-mode are modified so the requirement to
order accesses to device I/O implies also the requirement to order main
memory accesses. <<senvcfg_FIOM>> details the modified
interpretation of FENCE instruction bits PI, PO, SI, and SO in U-mode
when FIOM=1.

[[norm:senvcfg_fiom_op_atomic]]
Similarly, for U-mode when FIOM=1, if an atomic instruction that
accesses a region ordered as device I/O has its _aq_ and/or _rl_ bit
set, then that instruction is ordered as though it accesses both device
I/O and memory.

[[norm:senvcfg_fiom_acc]]
If `satp`.MODE is read-only zero (always Bare), the implementation may
make FIOM read-only zero.

[[senvcfg_FIOM]]
.Modified interpretation of FENCE predecessor and successor sets in U-mode when FIOM=1.
[%autowidth,float="center",align="center",cols="^,<",options="header"]
|===
|Instruction bit |Meaning when set
|PI +
PO
|Predecessor device input and memory reads (PR implied) +
Predecessor device output and memory writes (PW implied)
|SI +
SO
|Successor device input and memory reads (SR implied) +
Successor device output and memory writes (SW implied)
|===

[NOTE]
====
Bit FIOM exists for a specific circumstance when an I/O device is being
emulated for U-mode and both of the following are true: (a) the emulated
device has a memory buffer that should be I/O space but is actually
mapped to main memory via address translation, and (b) multiple physical
harts are involved in accessing this emulated device from U-mode.

A hypervisor running in S-mode without the benefit of the hypervisor
extension of <<hypervisor>> may need to emulate
a device for U-mode if paravirtualization cannot be employed. If the
same hypervisor provides a virtual machine (VM) with multiple virtual
harts, mapped one-to-one to real harts, then multiple harts may
concurrently access the emulated device, perhaps because: (a) the guest
OS within the VM assigns device interrupt handling to one hart while the
device is also accessed by a different hart outside of an interrupt
handler, or (b) control of the device (or partial control) is being
migrated from one hart to another, such as for interrupt load balancing
within the VM. For such cases, guest software within the VM is expected
to properly coordinate access to the (emulated) device across multiple
harts using mutex locks and/or interprocessor interrupts as usual, which
in part entails executing I/O fences. But those I/O fences may not be
sufficient if some of the device ``I/O'' is actually main memory,
unknown to the guest. Setting FIOM=1 modifies those fences (and all
other I/O fences executed in U-mode) to include main memory, too.

Software can always avoid the need to set FIOM by never using main
memory to emulate a device memory buffer that should be I/O space.
However, this choice usually requires trapping all U-mode accesses to
the emulated buffer, which might have a noticeable impact on
performance. The alternative offered by FIOM is sufficiently inexpensive
to implement that we consider it worth supporting even if only rarely
enabled.
====

[[norm:senvcfg_cbze]]
The Zicboz extension adds the `CBZE` (Cache Block Zero instruction enable) field
to `senvcfg`. The `CBZE` field controls execution of the cache block zero
instruction (`CBO.ZERO`) in U-mode. Execution of `CBO.ZERO` in U-mode is enabled
only if execution of the instruction is enabled for use in S-mode and `CBZE` is
set to 1; otherwise, an illegal-instruction exception is raised. When the Zicboz
extension is not implemented, `CBZE` is read-only zero.

[[norm:senvcfg_cbcfe]]
The Zicbom extension adds the `CBCFE` (Cache Block Clean and Flush instruction
Enable) field to `senvcfg` to control execution of the `CBO.CLEAN` and
`CBO.FLUSH` instructions in U-mode. Execution of these instructions in U-mode is
enabled only if execution of these instructions is enabled for use in S-mode and
`CBCFE` is set to 1; otherwise, an illegal-instruction exception is raised. When
the Zicbom extension is not implemented, `CBCFE` is read-only zero.

[[norm:senvcfg_cbie]]
The Zicbom extension adds the `CBIE` (Cache Block Invalidate instruction Enable)
WARL field to `senvcfg` to control execution of the `CBO.INVAL` instruction in
U-mode. The encoding `0b10` is reserved. When the Zicbom extension is not
implemented, `CBIE` is read-only zero. Execution of `CBO.INVAL` in U-mode is
enabled only if execution of the instruction is enabled for use in S-mode and
`CBIE` is set to `0b01` or `0b11`; otherwise, an illegal-instruction exception is
raised.

[#norm:cbo-inval_s-mode_op0]#If `CBO.INVAL` is enabled in S-mode to perform a flush operation, then when the
instruction is enabled in U-mode it performs a flush operation, even if `CBIE`
is set to `0b11`. Otherwise, the instruction behaves as follows, depending on the
`CBIE` encoding:#

* [[norm:cbo-inval_s-mode_op1]]`0b01` -- The instruction is executed and performs a flush operation.
* [[norm:cbo-inval_s-mode_op2]]`0b11` -- The instruction is executed and performs an invalidate operation.

[[norm:senvcfg_pmm_Ssnpm]]
If the Ssnpm extension is implemented, the `PMM` field enables or disables
pointer masking (see <<Zpm>>) for the next-lower privilege mode (U/VU),
according to the values in <<senvcfg_pmm-values>>. If Ssnpm is not
implemented, `PMM` is read-only zero. The `PMM` field is read-only zero for
RV32.

[[senvcfg_pmm-values]]

[%header, cols="25%,75%", options="header"]
.Legal values of `PMM` WARL field
|===
|Value|Description
|00|Pointer masking is disabled (PMLEN = 0)
|01|Reserved
|10|Pointer masking is enabled with PMLEN = XLEN - 57 (PMLEN = 7 on RV64)
|11|Pointer masking is enabled with PMLEN = XLEN - 48 (PMLEN = 16 on RV64)
|===

[[norm:senvcfg_lpe_Zicfilp]]
The Zicfilp extension adds the `LPE` field in `senvcfg`. When the `LPE` field is
set to 1, the Zicfilp extension is enabled in VU/U-mode. When the `LPE` field is
0, the Zicfilp extension is not enabled in VU/U-mode and the following rules
apply to VU/U-mode:

* The hart does not update the `ELP` state; it remains as `NO_LP_EXPECTED`.
* The `LPAD` instruction operates as a no-op.

[[norm:senvcfg_sse_Zicfilp]]
The Zicfiss extension adds the `SSE` field in `senvcfg`. When the `SSE` field is
set to 1, the Zicfiss extension is activated in VU/U-mode. When the `SSE` field
is 0, the Zicfiss extension remains inactive in VU/U-mode, and the following
rules apply:

* 32-bit Zicfiss instructions will revert to their behavior as defined by Zimop.
* 16-bit Zicfiss instructions will revert to their behavior as defined by Zcmop.
* When `menvcfg.SSE` is one, `SSAMOSWAP.W/D` raises an illegal-instruction
  exception in U-mode and a virtual-instruction exception in VU-mode.

[[satp]]
==== Supervisor Address Translation and Protection (`satp`) Register

[[norm:satp]]
The `satp` CSR is an SXLEN-bit read/write register, formatted as
shown in <<rv32satp>> for SXLEN=32 and
<<rv64satp>> for SXLEN=64, which controls
supervisor-mode address translation and protection. This register holds
the physical page number (PPN) of the root page table, i.e., its
supervisor physical address divided by 4 KiB; an address space identifier
(ASID), which facilitates address-translation fences on a
per-address-space basis; and the MODE field, which selects the current
address-translation scheme. Further details on the access to this
register are described in <<virt-control>>.

[[rv32satp]]
.Supervisor address translation and protection (`satp`) register when SXLEN=32.
include::images/bytefield/rv32satp.edn[]

[NOTE]
====
Storing a PPN in `satp`, rather than a physical address, supports a
physical address space larger than 4 GiB for RV32.

The `satp`.PPN field might not be capable of holding all physical page
numbers. Some platform standards might place constraints on the values
`satp`.PPN may assume, e.g., by requiring that all physical page numbers
corresponding to main memory be representable.
====

[[rv64satp]]
.Supervisor address translation and protection (`satp`) register when SXLEN=64, for MODE values Bare, Sv39, Sv48, and Sv57.
include::images/bytefield/rv64satp.edn[]

[NOTE]
====
We store the ASID and the page table base address in the same CSR to
allow the pair to be changed atomically on a context switch. Swapping
them non-atomically could pollute the old virtual address space with new
translations, or vice-versa. This approach also slightly reduces the
cost of a context switch.
====

[[norm:satp_mode]]
<<satp_mode>> shows the encodings of the MODE field when
SXLEN=32 and SXLEN=64. When MODE=Bare, supervisor virtual addresses are
equal to supervisor physical addresses, and there is no additional
memory protection beyond the physical memory protection scheme described
in <<pmp>>. To select MODE=Bare, software must write
zero to the remaining fields of `satp` (bits 30–0 when SXLEN=32, or bits
59–0 when SXLEN=64). Attempting to select MODE=Bare with a nonzero
pattern in the remaining fields has an UNSPECIFIED effect on the value that the
remaining fields assume and an UNSPECIFIED effect on address translation and
protection behavior.

When SXLEN=32, the `satp` encodings corresponding to MODE=Bare and
ASID[8:7]=3 are designated for custom use, whereas the encodings
corresponding to MODE=Bare and ASID[8:7]≠3 are reserved
for future standard use. When SXLEN=64, all `satp` encodings
corresponding to MODE=Bare are reserved for future standard use.

[NOTE]
====
Version 1.11 of this standard stated that the remaining fields in `satp`
had no effect when MODE=Bare. Making these fields reserved facilitates
future definition of additional translation and protection modes,
particularly in RV32, for which all patterns of the existing MODE field
have already been allocated.
====

[[svbare]]
[#norm:svbare_satp_mode_bare]#If an implementation supports the Svbare extension, then the `satp`
register's MODE field must be capable of holding the value Bare.#

[[norm:satp_mode_sxlen32]]
When SXLEN=32, the only other valid setting for MODE is Sv32, a paged
virtual-memory scheme described in <<sv32>>.

[[norm:satp_mode_sxlen64]]
When SXLEN=64, three paged virtual-memory schemes are defined: Sv39,
Sv48, and Sv57, described in <<sv39>>, <<sv48>>,
and <<sv57>>, respectively. One additional scheme, Sv64, will be
defined in a later version of this specification. The remaining MODE
settings are reserved for future use and may define different
interpretations of the other fields in `satp`.

[[norm:satp_mode_op_unsupported]]
Implementations are not required to support all MODE settings, and if
`satp` is written with an unsupported MODE, the entire write has no
effect; no fields in `satp` are modified.

[[norm:asidlen]]
The number of ASID bits is UNSPECIFIED and may be zero. The number of implemented
ASID bits, termed _ASIDLEN_, may be determined by writing one to every
bit position in the ASID field, then reading back the value in `satp` to
see which bit positions in the ASID field hold a one. The
least-significant bits of ASID are implemented first: that is, if
ASIDLEN > 0, ASID[ASIDLEN-1:0] is writable. The maximal
value of ASIDLEN, termed ASIDMAX, is 9 for Sv32 or 16 for Sv39, Sv48,
and Sv57.

<<<

[[satp_mode]]
.Encoding of `satp` MODE field.
[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
|===
3+|SXLEN=32
|Value |Name |Description
|0 +
1
|Bare +
Sv32
|No translation or protection. +
Page-based 32-bit virtual addressing (see <<sv32>>).
3+|*SXLEN=64*
|Value |Name |Description
|0 +
1-7 +
8 +
9 +
10 +
11 +
12-13 +
14-15
|Bare +
- +
Sv39 +
Sv48 +
Sv57 +
Sv64 +
- +
-
|No translation or protection. +
_Reserved for standard use_ +
Page-based 39-bit virtual addressing (see <<sv39>>). +
Page-based 48-bit virtual addressing (see <<sv48>>). +
Page-based 57-bit virtual addressing (see <<sv57>>). +
_Reserved for page-based 64-bit virtual addressing._ +
_Reserved for standard use_ +
_Designated for custom use_
|===

[NOTE]
====
For many applications, the choice of page size has a substantial
performance impact. A large page size increases TLB reach and loosens
the associativity constraints on virtually indexed, physically tagged
caches. At the same time, large pages exacerbate internal fragmentation,
wasting physical memory and possibly cache capacity.

After much deliberation, we have settled on a conventional page size of
4 KiB for both RV32 and RV64. We expect this decision to ease the
porting of low-level runtime software and device drivers. The TLB reach
problem is ameliorated by transparent superpage support in modern
operating systems. cite:[transparent-superpages] Additionally, multi-level TLB hierarchies are quite
inexpensive relative to the multi-level cache hierarchies whose address
space they map.
====

[[norm:satp_op_active]]
The `satp` CSR is considered _active_ when the effective privilege
mode is S-mode or U-mode. Executions of the address-translation
algorithm may only begin using a given value of `satp` when `satp` is
active.

[NOTE]
====
Translations that began while `satp` was active are not required to
complete or terminate when `satp` is no longer active, unless an
SFENCE.VMA instruction matching the address and ASID is executed. The
SFENCE.VMA instruction must be used to ensure that updates to the
address-translation data structures are observed by subsequent implicit
reads to those structures by a hart.
====

[[norm:satp_op_sfence_vma]]
Note that writing `satp` does not imply any ordering constraints between
page-table updates and subsequent address translations, nor does it
imply any invalidation of address-translation caches. If the new address
space’s page tables have been modified, or if an ASID is reused, it may
be necessary to execute an SFENCE.VMA instruction (see
<<sfence.vma>>) after, or in some cases before, writing
`satp`.

[NOTE]
====
Not imposing upon implementations to flush address-translation caches
upon `satp` writes reduces the cost of context switches, provided a
sufficiently large ASID space.
====

[[stimecmp]]
==== Supervisor Timer (`stimecmp`) Register

[#norm:stimecmp_stimecmph_sz_acc]#The `stimecmp` CSR is a 64-bit register and
has 64-bit precision on all RV32 and RV64 systems.
In RV32 only, accesses to the `stimecmp` CSR access the low 32 bits,
while accesses to the `stimecmph` CSR access the high 32 bits of `stimecmp`.#

[[norm:mip_sip_stip_op]]
A supervisor timer interrupt becomes pending, as reflected in the STIP bit in
the `mip` and `sip` registers whenever `time` contains a value greater than or
equal to `stimecmp`, treating the values as unsigned integers.
If the result of this comparison changes, it is guaranteed to be reflected in
STIP eventually, but not necessarily immediately.
The interrupt remains posted until `stimecmp` becomes greater than `time`,
typically as a result of writing `stimecmp`.
The interrupt will be taken based on the standard interrupt enable and
delegation rules.

[NOTE]
====
A spurious timer interrupt might occur if an interrupt handler advances
`stimecmp` then immediately returns, because STIP might not yet have fallen in
the interim. All software should be written to assume this event is possible,
but most software should assume this event is extremely unlikely. It is almost
always more performant to incur an occasional spurious timer interrupt than to
poll STIP until it falls.
====

[NOTE]
====
In systems in which a supervisor execution environment (SEE) provides timer
facilities via an SBI function call, this SBI call will continue to support
requests to schedule a timer interrupt. The SEE will simply make use of
stimecmp, changing its value as appropriate. This ensures compatibility with
existing S-mode software that uses this SEE facility, while new S-mode software
takes advantage of stimecmp directly.)
====

=== Supervisor Instructions

In addition to the SRET instruction defined in <<otherpriv>>, one new supervisor-level instruction is provided.

[[sfence.vma]]
==== Supervisor Memory-Management Fence Instruction
include::images/wavedrom/sfencevma.edn[]


[[norm:sfence_vma_op]]
The supervisor memory-management fence instruction SFENCE.VMA is used to
synchronize updates to in-memory memory-management data structures with
current execution. Instruction execution causes implicit reads and
writes to these data structures; however, these implicit references are
ordinarily not ordered with respect to explicit loads and stores.
[#norm:sfence_vma_ordering]#Executing an SFENCE.VMA instruction guarantees that any previous stores
already visible to the current RISC-V hart are ordered before certain
implicit references by subsequent instructions in that hart to the
memory-management data structures. The specific set of operations
ordered by SFENCE.VMA is determined by _rs1_ and _rs2_, as described
below.# [#norm:sfence_vma_invalidation]#SFENCE.VMA is also used to invalidate entries in the
address-translation cache associated with a hart (see <<sv32algorithm>>).# Further details on the behavior of this instruction are described in <<virt-control>> and <<pmp-vmem>>.

[NOTE]
====
The SFENCE.VMA is used to flush any local hardware caches related to
address translation. It is specified as a fence rather than a TLB flush
to provide cleaner semantics with respect to which instructions are
affected by the flush operation and to support a wider variety of
dynamic caching structures and memory-management schemes. SFENCE.VMA is
also used by higher privilege levels to synchronize page table writes
and the address translation hardware.
====

SFENCE.VMA orders only the local hart’s implicit references to the
memory-management data structures.

[NOTE]
====
Consequently, other harts must be notified separately when the
memory-management data structures have been modified. One approach is to
use 1) a local data fence to ensure local writes are visible globally,
then 2) an interprocessor interrupt to the other thread, then 3) a local
SFENCE.VMA in the interrupt handler of the remote thread, and finally 4)
signal back to originating thread that operation is complete. This is,
of course, the RISC-V analog to a TLB shootdown.
====

For the common case that the translation data structures have only been
modified for a single address mapping (i.e., one page or superpage),
_rs1_ can specify a virtual address within that mapping to effect a
translation fence for that mapping only. Furthermore, for the common
case that the translation data structures have only been modified for a
single address-space identifier, _rs2_ can specify the address space.
The behavior of SFENCE.VMA depends on _rs1_ and _rs2_ as follows:


* [#norm:sfence_vma_all_asid_va]#If __rs1__=`x0` and __rs2__=`x0`, the fence orders all reads and writes
made to any level of the page tables, for all address spaces. The fence
also invalidates all address-translation cache entries, for all address
spaces.#

* [#norm:sfence_vma_asid_only]#If __rs1__=`x0` and __rs2__{ne}``x0``, the fence orders all
reads and writes made to any level of the page tables, but only for the
address space identified by integer register _rs2_. Accesses to _global_
mappings (see <<translation>>) are not ordered. The
fence also invalidates all address-translation cache entries matching
the address space identified by integer register _rs2_, except for
entries containing global mappings.#

* [#norm:sfence_vma_va_all_asid]#If __rs1__{ne}``x0`` and __rs2__=`x0`, the fence orders only
reads and writes made to leaf page table entries corresponding to the
virtual address in __rs1__, for all address spaces. The fence also
invalidates all address-translation cache entries that contain leaf page
table entries corresponding to the virtual address in _rs1_, for all
address spaces.#

* [#norm:sfence_vma_va_asid]#If __rs1__{ne}``x0`` and __rs2__{ne}``x0``, the
fence orders only reads and writes made to leaf page table entries
corresponding to the virtual address in _rs1_, for the address space
identified by integer register _rs2_. Accesses to global mappings are
not ordered. The fence also invalidates all address-translation cache
entries that contain leaf page table entries corresponding to the
virtual address in _rs1_ and that match the address space identified by
integer register _rs2_, except for entries containing global mappings.#

[[norm:sfence_vma_invalid_va]]
If the value held in _rs1_ is not a valid virtual address, then the
SFENCE.VMA instruction has no effect. No exception is raised in this
case.

[NOTE]
====
It is always legal to over-fence, e.g., by fencing only based on a
subset of the bits in _rs1_ and/or _rs2_, and/or by simply treating all
SFENCE.VMA instructions as having _rs1_=`x0` and/or _rs2_=`x0`. For
example, simpler implementations can ignore the virtual address in _rs1_
and the ASID value in _rs2_ and always perform a global fence. The
choice not to raise an exception when an invalid virtual address is held
in _rs1_ facilitates this type of simplification.
====

[[norm:sfence_vma_rs2_bits]]
When __rs2__{ne}``x0``, bits SXLEN-1:ASIDMAX of the value held
in _rs2_ are reserved for future standard use. Until their use is
defined by a standard extension, they should be zeroed by software and
ignored by current implementations. Furthermore, if
ASIDLEN<ASIDMAX, the implementation shall ignore bits
ASIDMAX-1:ASIDLEN of the value held in _rs2_.

[[norm:sfence_vma_ordering_semantics]]
An implicit read of the memory-management data structures may return any
translation for an address that was valid at any time since the most
recent SFENCE.VMA that subsumes that address. The ordering implied by
SFENCE.VMA does not place implicit reads and writes to the
memory-management data structures into the global memory order in a way
that interacts cleanly with the standard RVWMO ordering rules. In
particular, even though an SFENCE.VMA orders prior explicit accesses
before subsequent implicit accesses, and those implicit accesses are
ordered before their associated explicit accesses, SFENCE.VMA does not
necessarily place prior explicit accesses before subsequent explicit
accesses in the global memory order. These implicit loads also need not
otherwise obey normal program order semantics with respect to prior
loads or stores to the same address.

[NOTE]
====
A consequence of this specification is that an implementation may use
any translation for an address that was valid at any time since the most
recent SFENCE.VMA that subsumes that address.

For example, if a leaf PTE is modified and the corresponding virtual address
is accessed without a subsuming SFENCE.VMA having been executed in between,
then either the new translation or any older translation since the last
subsuming SFENCE.VMA was executed will be used.
It is unpredictable which translation will be chosen from that set, and
subsequent accesses to the same virtual address might use different
translations from that set.
But the behavior of such accesses is otherwise well defined.

This property applies even if the virtual-address width for that translation
differs from the width currently specified by `satp`.MODE.
For a given virtual address and ASID, any translation since the last subsuming
SFENCE.VMA might be used, even if that translation used a virtual address of a
different width.
Similarly, for a given virtual address, any global translation since the
last subsuming SFENCE.VMA might be used, regardless of both ASID and
virtual-address width.

In a conventional TLB design, it is possible for multiple entries to
match a single address if, for example, a page is upgraded to a
superpage without first clearing the original non-leaf PTE’s valid bit
and executing an SFENCE.VMA with __rs1__=`x0`. In this case, a similar
remark applies: it is unpredictable whether the old non-leaf PTE or the
new leaf PTE is used, but the behavior is otherwise well defined.

Another consequence of this specification is that it is generally unsafe
to update a PTE using a set of stores of a width less than the width of
the PTE, as it is legal for the implementation to read the PTE at any
time, including when only some of the partial stores have taken effect.

***

This specification permits the caching of PTEs whose V (Valid) bit is
clear. Operating systems must be written to cope with this possibility,
but implementers are reminded that eagerly caching invalid PTEs will
reduce performance by causing additional page faults.
====

[[norm:sfence_vma_implicit_access]]
Implementations must only perform implicit reads of the translation data
structures pointed to by the current contents of the `satp` register or
a subsequent valid (V=1) translation data structure entry, and must only
raise exceptions for implicit accesses that are generated as a result of
instruction execution, not those that are performed speculatively.

[#norm:sfence_vma_sum_mxr_effect]#Changes to the `sstatus` fields SUM and MXR take effect immediately,
without the need to execute an SFENCE.VMA instruction.#
[#norm:sfence_vma_mode_effect]#Changing
`satp`.MODE from Bare to other modes and vice versa also takes effect
immediately, without the need to execute an SFENCE.VMA instruction.#
[#norm:sfence_vma_asid_effect]#Likewise, changes to `satp`.ASID take effect immediately.#

[NOTE]
====
The following common situations typically require executing an
SFENCE.VMA instruction:

* When software recycles an ASID (i.e., reassociates it with a different
page table), it should _first_ change `satp` to point to the new page
table using the recycled ASID, _then_ execute SFENCE.VMA with __rs1__=`x0`
and _rs2_ set to the recycled ASID. Alternatively, software can execute
the same SFENCE.VMA instruction while a different ASID is loaded into
`satp`, provided the next time `satp` is loaded with the recycled ASID,
it is simultaneously loaded with the new page table.
* If the implementation does not provide ASIDs, or software chooses to
always use ASID 0, then after every `satp` write, software should
execute SFENCE.VMA with __rs1__=`x0`. In the common case that no global
translations have been modified, _rs2_ should be set to a register other
than `x0` but which contains the value zero, so that global translations
are not flushed.
* If software modifies a non-leaf PTE, it should execute SFENCE.VMA with
__rs1__=`x0`. If any PTE along the traversal path had its G bit set, _rs2_
must be `x0`; otherwise, _rs2_ should be set to the ASID for which the
translation is being modified.
* If software modifies a leaf PTE, it should execute SFENCE.VMA with
_rs1_ set to a virtual address within the page. If any PTE along the
traversal path had its G bit set, _rs2_ must be `x0`; otherwise, _rs2_
should be set to the ASID for which the translation is being modified.
* For the special cases of increasing the permissions on a leaf PTE and
changing an invalid PTE to a valid leaf, software may choose to execute
the SFENCE.VMA lazily. After modifying the PTE but before executing
SFENCE.VMA, either the new or old permissions will be used. In the
latter case, a page-fault exception might occur, at which point software
should execute SFENCE.VMA in accordance with the previous bullet point.
====

[[norm:asid_hart_private]]
If a hart employs an address-translation cache, that cache must appear
to be private to that hart. In particular, the meaning of an ASID is
local to a hart; software may choose to use the same ASID to refer to
different address spaces on different harts.

[NOTE]
====
A future extension could redefine ASIDs to be global across the SEE,
enabling such options as shared translation caches and hardware support
for broadcast TLB shootdown. However, as OSes have evolved to
significantly reduce the scope of TLB shootdowns using novel
ASID-management techniques, we expect the local-ASID scheme to remain
attractive for its simplicity and possibly better scalability.
====

[[norm:satp_mode_roz_sfence_illegal]]
For implementations that make `satp`.MODE read-only zero (always Bare),
attempts to execute an SFENCE.VMA instruction might raise an
illegal-instruction exception.

No SFENCE.VMA is required after enabling or disabling pointer masking
(see <<Zpm>>), as pointer masking applies to the effective address only and
does not affect any memory-management data structures.

[[sv32]]
=== Sv32: Page-Based 32-bit Virtual-Memory Systems

When Sv32 is written to the MODE field in the `satp` register (see
<<satp>>), the supervisor operates in a 32-bit paged
virtual-memory system. In this mode, supervisor and user virtual
addresses are translated into supervisor physical addresses by
traversing a radix-tree page table. Sv32 is supported when SXLEN=32 and
is designed to include mechanisms sufficient for supporting modern
Unix-based operating systems.

[NOTE]
====
The initial RISC-V paged virtual-memory architectures have been designed
as straightforward implementations to support existing operating
systems. We have architected page table layouts to support a hardware
page-table walker. Software TLB refills are a performance bottleneck on
high-performance systems, and are especially troublesome with decoupled
specialized coprocessors. An implementation can choose to implement
software TLB refills using a machine-mode trap handler as an extension
to M-mode.

***

Some ISAs architecturally expose _virtually indexed, physically tagged_
caches, in that accesses to the same physical address via different
virtual addresses might not be coherent unless the virtual addresses lie
within the same cache set. Implicitly, this specification does not
permit such behavior to be architecturally exposed.
====

[[translation]]
==== Addressing and Memory Protection

Sv32 implementations support a 32-bit virtual address space, divided
into 4 KiB pages. An Sv32 virtual address is partitioned into a virtual page
number (VPN) and page offset, as shown in <<sv32va>>.
When Sv32 virtual memory mode is selected in the MODE field of the
`satp` register, supervisor virtual addresses are translated into
supervisor physical addresses via a two-level page table. The 20-bit VPN
is translated into a [#norm:satp_ppn_sv32_sz]#22-bit physical page number (PPN)#,
while the 12-bit page offset is untranslated. The resulting supervisor-level physical
addresses are then checked using any physical memory protection
structures (<<pmp>>), before being directly
converted to machine-level physical addresses. If necessary,
supervisor-level physical addresses are zero-extended to the number of
physical address bits found in the implementation.

[NOTE]
====
For example, consider an RV32 system supporting 34 bits of physical
address. When the value of `satp`.MODE is Sv32, a 34-bit physical
address is produced directly, and therefore no zero extension is needed.
When the value of `satp`.MODE is Bare, the 32-bit virtual address is
translated (unmodified) into a 32-bit physical address, and then that
physical address is zero-extended into a 34-bit machine-level physical
address.
====
[[sv32va]]
.Sv32 virtual address.
include::images/bytefield/sv32va.edn[]


Sv32 page tables consist of 2^10^ page-table entries
(PTEs), each of four bytes. A page table is exactly the size of a page
and must always be aligned to a page boundary. The physical page number
of the root page table is stored in the `satp` register.

[[sv32pa]]
.SV32 physical address.
include::images/bytefield/sv32pa.edn[]

[[sv32pte]]
.Sv32 page table entry.
include::images/bytefield/sv32pte.edn[]

The PTE format for Sv32 is shown in <<sv32pte>>.
The V bit indicates whether the PTE is valid; if it is 0, all other bits
in the PTE are don’t-cares and may be used freely by software. The
permission bits, R, W, and X, indicate whether the page is readable,
writable, and executable, respectively. When all three are zero, the PTE
is a pointer to the next level of the page table; otherwise, it is a
leaf PTE. Writable pages must also be marked readable; the contrary
combinations are reserved for future use. <<pteperm>>
summarizes the encoding of the permission bits.

[[pteperm]]
.Encoding of PTE R/W/X fields.
[%autowidth,float="center",align="center",cols="^,^,^,<",options="header"]
|===
|X |W |R |Meaning
|0 +
0 +
0 +
0 +
1 +
1 +
1 +
1
|0 +
0 +
1 +
1 +
0 +
0 +
1 +
1
|0 +
1 +
0 +
1 +
0 +
1 +
0 +
1
|Pointer to next level of page table. +
Read-only page. +
_Reserved for future use._ +
Read-write page. +
Execute-only page. +
Read-execute page. +
_Reserved for future use._ +
Read-write-execute page.
|===

[#norm:fetch_page_fault_no_x]#Attempting to fetch an instruction from a page that does not have
execute permissions raises a fetch page-fault exception.#
[#norm:load_page_fault_no_r]#Attempting to execute a load, load-reserved, or cache-block management
instruction whose effective address lies
within a page without read permissions raises a load page-fault exception.#
[#norm:store_page_fault_no_w]#Attempting to execute a store, store-conditional, AMO, or cache-block zero instruction
instruction whose effective address lies within a page without write
permissions raises a store page-fault exception.#

[NOTE]
====
AMOs never raise load page-fault exceptions. Since any unreadable page
is also unwritable, attempting to perform an AMO on an unreadable page
always raises a store page-fault exception.
====

The U bit indicates whether the page is accessible to user mode. U-mode
software may only access the page when U=1. If the SUM bit in the
`sstatus` register is set, supervisor mode software may also access
pages with U=1. However, supervisor code normally operates with the SUM
bit clear, in which case, supervisor code will fault on accesses to
user-mode pages. Irrespective of SUM, the supervisor may not execute
code on pages with U=1.

[NOTE]
====
An alternative PTE format would support different permissions for
supervisor and user. We omitted this feature because it would be largely
redundant with the SUM mechanism (see <<sum>>) and would require more encoding space in the PTE.
====

The G bit designates a _global_ mapping. Global mappings are those that
exist in all address spaces. For non-leaf PTEs, the global setting
implies that all mappings in the subsequent levels of the page table are
global. Note that failing to mark a global mapping as global merely
reduces performance, whereas marking a non-global mapping as global is a
software bug that, after switching to an address space with a different
non-global mapping for that address range, can unpredictably result in
either mapping being used.

[NOTE]
====
Global mappings need not be stored redundantly in address-translation
caches for multiple ASIDs. Additionally, they need not be flushed from
local address-translation caches when an SFENCE.VMA instruction is
executed with __rs2__{ne}``x0``.
====

The RSW field is reserved for use by supervisor software; the
implementation shall ignore this field.

Each leaf PTE contains an accessed (A) and dirty (D) bit. The A bit
indicates the virtual page has been read, written, or fetched from since
the last time the A bit was cleared. The D bit indicates the virtual
page has been written since the last time the D bit was cleared.

Two schemes to manage the A and D bits are defined:

[[svade]]
* [#norm:svade_access_ad_bit_clear]#The _Svade_ extension: when a virtual page is accessed and the A bit is
  clear, or is written and the D bit is clear, a page-fault exception is
  raised.#

* When the Svade extension is not implemented, the following scheme applies. +
                                                                          +
  When a virtual page is accessed and the A bit is clear, the PTE is
  updated to set the A bit.  When the virtual page is written and the D
  bit is clear, the PTE is updated to set the D bit. When G-stage address
  translation is in use and is not Bare, the G-stage virtual pages may be
  accessed or written by implicit accesses to VS-level memory management
  data structures, such as page tables.                                 +
                                                                        +
  When two-stage address translation is in use, an explicit access may
  cause both VS-stage and G-stage PTEs to be updated. The following rules
  apply to all PTE updates caused by an explicit or an implicit memory
  accesses.                                                             +
                                                                   +
  The PTE update must be atomic with respect to other accesses to the
  PTE, and must atomically perform all page-table walk checks for that leaf
  PTE as part of, and before, conditionally updating the PTE value.
  Updates of the A bit may be performed as a result of speculation, even
  if the associated memory access ultimately is not performed
  architecturally. However, updates to the D bit, resulting from an
  explicit store, must be exact (i.e., non-speculative), and observed in
  program order by the local hart. When two-stage address translation is
  active, updates to the D bit in G-stage PTEs may be performed by an
  implicit access to a VS-stage PTE, if the G-stage PTE provides write
  permission, before any speculative access to the VS-stage PTE.        +
                                                                        +
  The PTE update must appear in the global memory order before the
  memory access that caused the PTE update and before any subsequent
  explicit memory access to that virtual page by the local hart. The
  ordering on loads and stores provided by FENCE instructions and the
  acquire/release bits on atomic instructions also orders the PTE updates
  associated with those loads and stores as observed by remote harts.   +
                                                                        +
  The PTE update is not required to be atomic with respect to the memory
  access that caused the update and a trap may occur between the PTE
  update and the memory access that caused the PTE update. If a trap
  occurs then the A and/or D bit may be updated but the memory access
  that caused the PTE update might not occur. The hart must not perform
  the memory access that caused the PTE update before the PTE update is
  globally visible.                                                     +
                                                                        +
  The page tables must be located in memory with hardware page-table
  write access and _RsrvEventual_ PMA.

All harts in a system must employ the same PTE-update scheme as each
other.

[NOTE]
====
The PTE updates due to memory accesses ordered-after a FENCE are not
themselves ordered by the FENCE.

Simpler implementations may order the Page Table Entry (PTE) update
to precede all subsequent explicit memory accesses, as opposed to
ensuring that the PTE update is precisely sequenced before subsequent
explicit memory accesses to the associated virtual page.

Prior versions of this specification required PTE A bit updates to be
exact, but allowing the A bit to be updated as a result of speculation
simplifies the implementation of address translation prefetchers. System
software typically uses the A bit as a page replacement policy hint, but
does not require exactness for functional correctness. On the other
hand, D bit updates are still required to be exact and performed in
program order, as the D bit affects the functional correctness of page
eviction.

Implementations are of course still permitted to perform both A and D
bit updates only in an exact manner.

In both cases, requiring atomicity ensures that the PTE update will not
be interrupted by other intervening writes to the page table, as such
interruptions could lead to A/D bits being set on PTEs that have been
reused for other purposes, on memory that has been reclaimed for other
purposes, and so on. Simple implementations may instead generate
page-fault exceptions.

The A and D bits are never cleared by the implementation. If the
supervisor software does not rely on accessed and/or dirty bits, e.g. if
it does not swap memory pages to secondary storage or if the pages are
being used to map I/O space, it should always set them to 1 in the PTE
to improve performance.
====

Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv32
supports 4 MiB _megapages_. A megapage must be virtually and physically
aligned to a 4 MiB boundary; a page-fault exception is raised if the
physical address is insufficiently aligned.

For non-leaf PTEs, the D, A, and U bits are reserved for future standard
use. Until their use is defined by a standard extension, they must be
cleared by software for forward compatibility.

For implementations with both page-based virtual memory and the ext:a[]
standard extension, the LR/SC reservation set must lie completely within
a single base physical page (i.e., a naturally aligned 4 KiB physical-memory
region).

On some implementations, misaligned loads, stores, and instruction
fetches may also be decomposed into multiple accesses, some of which may
succeed before a page-fault exception occurs. In particular, a
portion of a misaligned store that passes the exception check may become
visible, even if another portion fails the exception check. The same behavior
may manifest for stores wider than XLEN bits (e.g., the FSD instruction
in RV32D), even when the store address is naturally aligned.


[[sv32algorithm]]
==== Virtual Address Translation Process

A virtual address _va_ is translated into a physical address _pa_ as follows:

. Let _a_ be ``satp``.__ppn__×PAGESIZE, and let __i__=LEVELS-1. (For Sv32, PAGESIZE=2^12^ and LEVELS=2.) The `satp` register must be
_active_, i.e., the effective privilege mode must be S-mode or U-mode.

. Let _pte_ be the value of the PTE at address __a__+__va__.__vpn__[__i__]×PTESIZE. (For Sv32, PTESIZE=4.)  If accessing _pte_ violates a PMA or PMP check, raise an access-fault exception corresponding to the original access type.

. If _pte_._v_=0, or if _pte_._r_=0 and _pte_._w_=1, or if any bits or encodings that are reserved for future standard use are set within _pte_, stop and raise a page-fault exception corresponding to the original access type.

. Otherwise, the PTE is valid. If __pte__.__r__=1 or __pte__.__x__=1, go to step 5. Otherwise, this PTE is a pointer to the next level of the page table. Let __i=i__-1. If __i__<0, stop and raise a page-fault exception corresponding to the original access type. Otherwise, let
__a__=__pte__.__ppn__×PAGESIZE and go to step 2.

. A leaf PTE has been reached. If _i>0_ and _pte_._ppn_[__i__-1:0] ≠ 0, this is a misaligned superpage; stop and raise a page-fault exception corresponding to the original access type.

. Determine if the requested memory access is allowed by the _pte_._u_ bit, given the current privilege mode and the value of the SUM and MXR fields of the *mstatus* register. If not, stop and raise a page-fault exception corresponding to the original access type.

. Determine if the requested memory access is allowed by the _pte_._r_, _pte_._w_, and _pte_._x_ bits, given the Shadow Stack Memory Protection rules. If not, stop and raise an access-fault exception.

. Determine if the requested memory access is allowed by the _pte_._r_, _pte_._w_, and _pte_._x_ bits. If not, stop and raise a page-fault exception corresponding to the original access type.

. If _pte_._a_=0, or if the original memory access is a store and _pte_._d_=0:

* If the Svade extension is implemented, stop and raise a page-fault exception corresponding to the original access type.
* If a store to the PTE at address __a__+__va.vpn__[__i__]×PTESIZE would violate a PMA or PMP check,
raise an access-fault exception corresponding to the original access
type.
* Perform the following steps atomically:
** Compare _pte_ to the value of the PTE at address __a__+__va.vpn__[__i__]×PTESIZE.
** If the values match, set _pte_._a_ to 1 and, if the
original memory access is a store, also set _pte_._d_ to 1. Then store _pte_ to the PTE at address __a__+__va.vpn__[__i__]×PTESIZE.
** If the comparison fails, return to step 2.

. The translation is successful. The translated physical address is
given as follows:
* _pa.pgoff_ = _va.pgoff_.
* If _i_>0, then this is a superpage translation and __pa.ppn__[__i__-1:0] = __va.vpn__[__i__-1:0].
* _pa.ppn_[LEVELS-1:__i__] = _pte_._ppn_[LEVELS-1:__i__].

All implicit accesses to the address-translation data structures in this
algorithm are performed using width PTESIZE.

[NOTE]
====
This implies, for example, that an Sv48 implementation may not use two
separate 4{nbsp}B reads to non-atomically access a single 8{nbsp}B PTE, and that A/D
bit updates performed by the implementation are treated as atomically
updating the entire PTE, rather than just the A and/or D bit alone (even
though the PTE value does not otherwise change).
====

The results of implicit address-translation reads in step 2 may be held
in a read-only, incoherent _address-translation cache_ but not shared
with other harts. The address-translation cache may hold an arbitrary
number of entries, including an arbitrary number of entries for the same
address and ASID. Entries in the address-translation cache may then
satisfy subsequent step 2 reads if the ASID associated with the entry
matches the ASID loaded in step 0 or if the entry is associated with a
_global_ mapping. To ensure that implicit reads observe writes to the
same memory locations, an SFENCE.VMA instruction must be executed after
the writes to flush the relevant cached translations.

The address-translation cache cannot be used in step 9; accessed and
dirty bits may only be updated in memory directly.
[NOTE]
====
It is permitted for multiple address-translation cache entries to
co-exist for the same address. This represents the fact that in a
conventional TLB hierarchy, it is possible for multiple entries to match
a single address if, for example, a page is upgraded to a superpage
without first clearing the original non-leaf PTE’s valid bit and
executing an SFENCE.VMA with _rs1_=`x0`, or if multiple TLBs exist in
parallel at a given level of the hierarchy. In this case, just as if an
SFENCE.VMA is not executed between a write to the memory-management
tables and subsequent implicit read of the same address: it is
unpredictable whether the old non-leaf PTE or the new leaf PTE is used,
but the behavior is otherwise well defined.
====

Implementations may also execute the address-translation algorithm
speculatively at any time, for any virtual address, as long as `satp` is
active (as defined in <<satp>>). Such speculative
executions have the effect of pre-populating the address-translation
cache.

Speculative executions of the address-translation algorithm behave as
non-speculative executions of the algorithm do, except that they must
not set the dirty bit for a PTE, they must not trigger an exception, and
they must not create address-translation cache entries if those entries
would have been invalidated by any SFENCE.VMA instruction executed by
the hart since the speculative execution of the algorithm began.

[NOTE]
====
For instance, it is illegal for both non-speculative and speculative
executions of the translation algorithm to begin, read the level 2 page
table, pause while the hart executes an SFENCE.VMA with
_rs1_=_rs2_=`x0`, then resume using the now-stale level 2 PTE, as
subsequent implicit reads could populate the address-translation cache
with stale PTEs.

In many implementations, an SFENCE.VMA instruction with _rs1_=`x0` will
therefore either terminate all previously-launched speculative
executions of the address-translation algorithm (for the specified ASID,
if applicable), or simply wait for them to complete (in which case any
address-translation cache entries created will be invalidated by the
SFENCE.VMA as appropriate). Likewise, an SFENCE.VMA instruction with
__rs1__≠``x0`` generally must either ensure that
previously-launched speculative executions of the address-translation
algorithm (for the specified ASID, if applicable) are prevented from
creating new address-translation cache entries mapping leaf PTEs, or
wait for them to complete.

A consequence of implementations being permitted to read the translation
data structures arbitrarily early and speculatively is that at any time,
all page table entries reachable by executing the algorithm may be
loaded into the address-translation cache.

Although it would be uncommon to place page tables in non-idempotent
memory, there is no explicit prohibition against doing so. Since the
algorithm may only touch page tables reachable from the root page table
indicated in `satp`, the range of addresses that an implementation's
page-table walker will touch is fully under supervisor control.

***

The algorithm does not admit the possibility of ignoring high-order PPN
bits for implementations with narrower physical addresses.
====

[[sv39]]
=== Sv39: Page-Based 39-bit Virtual-Memory System

This section describes a [#norm:Sv39_sxlen]#simple paged virtual-memory system for
SXLEN=64#, which [#norm:Sv39_va_sz]#supports 39-bit virtual address spaces#. The design of
Sv39 follows the overall scheme of Sv32, and this section details only
the differences between the schemes.

[NOTE]
====
We specified multiple virtual memory systems for RV64 to relieve the
tension between providing a large address space and minimizing
address-translation cost. For many systems, 39 bits of virtual-address space is
ample, and so Sv39 suffices. Sv48 increases the virtual address space to
48 bits, but increases the physical memory capacity dedicated to page tables,
the latency of page-table traversals, and the size of hardware
structures that store virtual addresses. Sv57 increases the virtual
address space, page table capacity requirement, and translation latency
even further.
====

[[addressing-and-memory-protection]]
==== Addressing and Memory Protection

Sv39 implementations support a 39-bit virtual address space, divided
into 4 KiB pages. An Sv39 address is partitioned as shown in
<<sv39va>>. Instruction fetch addresses and load and
store effective addresses, which are 64 bits,
[#norm:Sv39_va_signext]#must have bits 63–39 all equal to bit 38, or else
a page-fault exception will occur#.
The [#norm:Sv39_vpn_sz]#27-bit VPN# is translated into a
[#norm:satp_ppn_sv39_sz]#44-bit PPN# via a
[#norm:Sv39_levels]#three-level page table#, while the
[#norm:Sv39_page_offset_sz]#12-bit page offset is untranslated#.

[NOTE]
====
When mapping between narrower and wider addresses, RISC-V zero-extends a
narrower physical address to a wider size. The mapping between 64-bit
virtual addresses and the 39-bit usable address space of Sv39 is not
based on zero extension but instead follows an entrenched convention
that allows an OS to use one or a few of the most-significant bits of a
full-size (64-bit) virtual address to quickly distinguish user and
supervisor address regions.
====

[[sv39va]]
.Sv39 virtual address.
include::images/bytefield/sv39va.edn[]

[[sv39pa]]
.Sv39 physical address.
include::images/bytefield/sv39pa.edn[]

[[sv39pte]]
.Sv39 page table entry.
include::images/bytefield/sv39pte.edn[]

Sv39 page tables contain [#norm:Sv39_pte_count]#2^9^ page table entries
(PTEs)#, [#norm:Sv39_pte_sz]#eight bytes each#.
A page table is [#norm:Sv39_pt_sz]#exactly the size of a page# and
[#norm:Sv39_pt_align]#must always be aligned to a page boundary#.
The physical page number of the root page table is stored in the `satp`
register's PPN field.

The PTE format for Sv39 is shown in <<sv39pte>>.
Bits 9-0 have the same meaning as for Sv32.
Bit 63 is reserved for use by the extlink:svnapot[] extension.
[#norm:Sv39_pte_svnapot_rsv]#If Svnapot is not implemented, bit 63 remains
reserved and must be zeroed by software for forward compatibility, or
else a page-fault exception is raised#.
Bits 62-61 are reserved for use by the extlink:svpbmt[] extension.
[#norm:Sv39_pte_svpbmt_rsv]#If Svpbmt is not implemented, bits 62-61 remain
reserved and must be zeroed by software for forward compatibility, or
else a page-fault exception is raised#.
Bits 60-54 are reserved for future standard use and, until their use is
defined by some standard extension,
[#norm:Sv39_pte_future_rsv]#must be zeroed by software for forward
compatibility. If any of these bits are set, a page-fault exception is
raised#.

[NOTE]
====
We reserved several PTE bits for a possible extension that improves
support for sparse address spaces by allowing page-table levels to be
skipped, reducing memory usage and TLB refill latency. These reserved
bits may also be used to facilitate research experimentation. The cost
is reducing the physical address space, but 56 bits is presently ample. When it
no longer suffices, the reserved bits that remain unallocated could be
used to expand the physical address space.
====

[#norm:Sv39_leaf_any_level]#Any level of PTE may be a leaf PTE#, so in
addition to 4 KiB pages, Sv39 supports
[#norm:Sv39_page_sizes]#2 MiB megapages and 1 GiB gigapages#, each of
which [#norm:Sv39_superpage_align]#must be virtually and physically
aligned to a boundary equal to its size#.
[#norm:Sv39_superpage_align_fault]#A page-fault exception is raised if
the physical address is insufficiently aligned#.

The algorithm for virtual-to-physical address translation is the same as
in <<sv32algorithm>>, except
[#norm:Sv39_LEVELS]#LEVELS equals 3# and
[#norm:Sv39_PTESIZE]#PTESIZE equals 8#.

[[sv48]]
=== Sv48: Page-Based 48-bit Virtual-Memory System

This section describes a simple paged virtual-memory system for
[#norm:Sv48_sxlen]#SXLEN=64#, which supports
[#norm:Sv48_va_sz]#48-bit virtual address spaces#.
Sv48 is intended for systems for which a 39-bit virtual address space is
insufficient. It closely follows the design of Sv39, simply adding an
additional level of page table, and so this chapter only details the
differences between the two schemes.

[#norm:Sv48_requires_Sv39]#Implementations that support Sv48 must also
support Sv39#.

[NOTE]
====
Systems that support Sv48 can also support Sv39 at essentially no cost,
and so should do so to maintain compatibility with supervisor software
that assumes Sv39.
====

[[addressing-and-memory-protection-1]]
==== Addressing and Memory Protection

Sv48 implementations support a 48-bit virtual address space, divided
into 4 KiB pages. An Sv48 address is partitioned as shown in
<<sv48va>>. Instruction fetch addresses and load and
store effective addresses, which are 64 bits,
[#norm:Sv48_va_signext]#must have bits 63–48 all equal to bit 47, or else
a page-fault exception will occur#.
The [#norm:Sv48_vpn_sz]#36-bit VPN# is translated into a
[#norm:satp_ppn_sv48_sz]#44-bit PPN# via a
[#norm:Sv48_levels]#four-level page table#, while the
[#norm:Sv48_page_offset_sz]#12-bit page offset is untranslated#.

[[sv48va]]
.Sv48 virtual address.
include::images/bytefield/sv48va.edn[]

[[sv48pa]]
.Sv48 physical address.
include::images/bytefield/sv48pa.edn[]

[[sv48pte]]
.Sv48 page table entry.
include::images/bytefield/sv48pte.edn[]

The PTE format for Sv48 is shown in <<sv48pte>>.
Bits 63-54 and 9-0 have the same meaning as for Sv39.
[#norm:Sv48_leaf_any_level]#Any level of PTE may be a leaf PTE#, so in
addition to 4 KiB pages, Sv48 supports
[#norm:Sv48_page_sizes]#2 MiB megapages, 1 GiB gigapages, and
512 GiB terapages#, each of which
[#norm:Sv48_superpage_align]#must be virtually and physically aligned to
a boundary equal to its size#.
[#norm:Sv48_superpage_align_fault]#A page-fault exception is raised if
the physical address is insufficiently aligned#.


The algorithm for virtual-to-physical address translation is the same as
in <<sv32algorithm>>, except
[#norm:Sv48_LEVELS]#LEVELS equals 4# and
[#norm:Sv48_PTESIZE]#PTESIZE equals 8#.

[[sv57]]
=== Sv57: Page-Based 57-bit Virtual-Memory System

This section describes a simple paged virtual-memory system designed for
[#norm:Sv57_sxlen]#RV64 systems#, which supports
[#norm:Sv57_va_sz]#57-bit virtual address spaces#.
Sv57 is intended for systems for which a 48-bit virtual address space is
insufficient. It closely follows the design of Sv48, simply adding an
additional level of page table, and so this chapter only details the
differences between the two schemes.

[#norm:Sv57_requires_Sv48]#Implementations that support Sv57 must also
support Sv48#.

[NOTE]
====
Systems that support Sv57 can also support Sv48 at essentially no cost,
and so should do so to maintain compatibility with supervisor software
that assumes Sv48.
====

[[addressing-and-memory-protection-2]]
==== Addressing and Memory Protection


Sv57 implementations support a 57-bit virtual address space, divided
into 4 KiB pages. An Sv57 address is partitioned as shown in
<<sv57va>>. Instruction fetch addresses and load and
store effective addresses, which are 64 bits,
[#norm:Sv57_va_signext]#must have bits 63–57 all equal to bit 56, or else
a page-fault exception will occur#.
The [#norm:Sv57_vpn_sz]#45-bit VPN# is translated into a
[#norm:satp_ppn_sv57_sz]#44-bit PPN# via a
[#norm:Sv57_levels]#five-level page table#, while the
[#norm:Sv57_page_offset_sz]#12-bit page offset is untranslated#.

[[sv57va]]
.Sv57 virtual address.
include::images/bytefield/sv57va.edn[]

[[sv57pa]]
.Sv57 physical address.
include::images/bytefield/sv57pa.edn[]

[[sv57pte]]
.Sv57 page table entry.
include::images/bytefield/sv57pte.edn[]

The PTE format for Sv57 is shown in <<sv57pte>>.
Bits 63–54 and 9–0 have the same meaning as for Sv39.
[#norm:Sv57_leaf_any_level]#Any level of PTE may be a leaf PTE#, so in
addition to 4 KiB pages, Sv57 supports
[#norm:Sv57_page_sizes]#2 MiB megapages, 1 GiB gigapages, 512 GiB
terapages, and 256 TiB petapages#, each of which
[#norm:Sv57_superpage_align]#must be virtually and physically aligned to
a boundary equal to its size#.
[#norm:Sv57_superpage_align_fault]#A page-fault exception is raised if
the physical address is insufficiently aligned#.

The algorithm for virtual-to-physical address translation is the same as
in <<sv32algorithm>>, except
[#norm:Sv57_LEVELS]#LEVELS equals 5# and
[#norm:Sv57_PTESIZE]#PTESIZE equals 8#.