chapter3.adoc

Smsdid: Supervisor Domain Identifier and Protection Register

Smsdid defines an interface to program the active supervisor domain under which a hart is operating. The interface consists of M-mode CSRs msdcfg and mmpt. The SDID programmed via this interface is a local identifier for the hart and may be used to tag hart-local resources to access-control data associated with the supervisor domain. The SDID is unique only to a hart, hence, SDID must not be used to tag downstream transactions that are globally visible.

Note	For most typical usages, the SDID will remain stable over the life of the supervisor domain. However, the SDID can be changed at the cost of flushing any prior cached state that was associated with the SDID.

Machine-level Memory Protection Tables (mmpt)

The mmpt register is an XLEN-bit read/write register, formatted as shown in Register 1 for XLEN=32 and Register 2 for XLEN=64, which controls physical address protection for supervisor domains. This register holds the physical page number (PPN) of the root page of the memory protection tables (MPT), a supervisor domain identifier (SDID), which facilitates address protection fences on a per-supervisor-domain basis; and the MODE field, which selects the address protection scheme (MPT Mode to be enforced) for physical addresses. The MPT is a structure that holds the access permissions for a physical address and is looked up per the programmed MODE.

Attempts to read or write mmpt while executing in U or S-mode will raise an illegal instruction exception.

MMPT register (mmpt) when XLEN=32.

{reg: [
  {bits:  22, name: 'PPN (WARL)'},
  {bits:   2, name: 'WPRI'},
  {bits:   6, name: 'SDID (WARL)'},
  {bits:   2, name: 'Mode (WARL)'},
], config:{lanes: 2, hspace:1024}}

MMPT register (mmpt) when XLEN=64.

{reg: [
  {bits:  44, name: 'PPN (WARL)'},
  {bits:  10, name: 'WPRI'},
  {bits:   6, name: 'SDID (WARL)'},
  {bits:   4, name: 'Mode (WARL)'},
], config:{lanes: 2, hspace:1024}}

Encoding of mmpt MODE field for XLEN=32. shows the encodings of the MODE field when XLEN=32 and Encoding of mmpt MODE field for XLEN=64. shows the encodings of the MODE field when XLEN=64. When mmpt MODE=Bare, supervisor physical addresses have no MPT-based protection across supervisor domains beyond the physical memory protection scheme described in Section 3.7 of the RISC-V privileged architecture specification cite:[ISA]. In this case, the remaining fields (SDID, PPN) in mmpt must be set to zeros. When XLEN=32, the other valid setting for MODE is Smmpt34 to support read-write-execute access permissions for 34-bit system physical addresses.

When XLEN=64, other than BARE, the other valid settings for MODE are Smmpt[46 | 56] to support read-write-execute permissions for 46-bit and 56-bit system physical addresses.

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

Table 1. Encoding of mmptMODE field for XLEN=32.

Value	Name	Description
0	Bare	No supervisor domain protection across beyond the physical memory protection scheme described in Section 3.7 of the RISC-V privileged architecture specification cite:[ISA]
1	Smmpt34	Page-based supervisor domain protection for up to 34 bit physical addresses with RWX permissions per page
2-3	-	Reserved

Table 2. Encoding of mmptMODE field for XLEN=64.

Value	Name	Description
0	Bare	No supervisor domain protection across beyond the physical memory protection scheme described in Section 3.7 of the RISC-V privileged architecture specification cite:[ISA]
1	Smmpt46	Page-based supervisor domain protection for up to 46 bit physical addresses with RWX permissions per page
2	Smmpt56	Page-based supervisor domain protection for up to 56 bit physical addresses with RWX permissions per page
3-15	-	Reserved

Implementations are not required to support all defined MODE settings when XLEN=64. A write to mmpt with an unsupported MODE value is not ignored. Instead, the fields of mmpt are WARL in the normal way, when so indicated.

The mmpt.PPN refers to an MPTL3 table or an MPTL2 table based on physical address width (PAW). For 56 >= PAW > 46, MPTL3 table must be of size 2^(PAW-43) bytes and naturally aligned to that sized byte boundary. For 46 >= PAW > 32 the MPTL2 table must be of size 2^(PAW-22) bytes for Smmpt46 and Smmpt34, and must be naturally aligned to that sized byte boundary. In these modes, the lowest two bits of the physical page number (mmpt.PPN) in mmpt always read as zeros.

The number of SDID bits is UNSPECIFIED and may be zero. The number of implemented SDID bits, termed SDIDLEN, may be determined by writing one to every bit position in the SDID field, then reading back the value in mmpt to see which bit positions in the SDID field hold a one. The least-significant bits of SDID are implemented first: that is, if SDIDLEN > 0, SDID[SDIDLEN-1:0] is writable. The maximal value of SDIDLEN, termed SDIDMAX, is 6 for Smmpt[34 | 46 | 56].

The mmpt register is considered active for the purposes of the physical address protection algorithm unless the effective privilege mode is M.

Note that writing mmpt does not imply any ordering constraints between S-mode and G-stage page-table updates and subsequent address translations. If a supervisor domain’s MPT structure has been modified, or if a SDID is reused, it may be necessary to execute a MFENCE.SPA instruction before or after writing mmpt.

Machine supervisor domain configuration (msdcfg)

The msdcfg is a 32-bit read/write register, formatted as shown in Register 3. This CSR is used by M-mode software to specify the active configuration for capabilities of the supervisor domain when associated with a hart.
The following extensions use the msdcfg register to specify additional configuration for supervisor domains:

1. Smsdia uses msdcfg.SDICN to specify the active configuration for the supervisor domain interrupt controller associated with the hart.

2. Smsdedbg specifies the msdcfg.sdedbgalw bit to manage external-debug for a supervisor domain.

3. Smsdetrc specifies the msdcfg.sdetrcalw bit to manage external-trace for a supervisor domain.

4. Smqosid specifies the control bits SSM, SRL, SML and SQRID to enable the RDSM to manage QoS controls for supervisor domains.

Details of Smsdia, Smsdedbg, Smsdetrc and Smqosid are described in their respective sections in this specification.

msdcfg register

{reg: [
  {bits:  6, name: 'SDICN'},
  {bits:  1, name: 'SSM'},
  {bits:  1, name: 'SDEDBGALW'},
  {bits:  1, name: 'SDETRCALW'},
  {bits:  11, name: 'WPRI'},
  {bits:  4, name: 'SRL'},
  {bits:  4, name: 'SML'},
  {bits:  4, name: 'SQRID'},
], config:{lanes: 4, hspace:1024}}

M-mode Supervisor Domain Fence Instruction

MFENCE.SPA instruction

{reg: [
  {bits:  7, name: 'opcode (SYSTEM)'},
  {bits:  5, name: 'rd (0)'},
  {bits:  3, name: 'func3 (PRIV)'},
  {bits:  5, name: 'rs1 (PADDR)'},
  {bits:  5, name: 'rs2 (SDID)'},
  {bits:  7, name: 'func7 (MFENCE.SPA)'},
], config:{lanes: 1, hspace:1024}}

The MFENCE.SPA fence instruction is used to synchronize updates to supervisor domain access-permissions with current execution. MFENCE.SPA is only valid in M-mode. If operand rs1≠x0, it specifies a single physical address, and if rs2≠x0, it specifies a single SDID.

If rs1 corresponds to an MPT_L1_DIR mapping, the fence applies to a 4 KiB page. If rs1 corresponds to a 2M_PAGES or 4M_PAGES mapping, the fence applies to a 2 MiB or 4 MiB range. If rs1 corresponds to one of the 1G_* mappings, the fence applies to a 1 GiB range.

The behavior of MFENCE.SPA depends on rs1 and rs2 as follows:

• If rs1=x0 and rs2=x0, the fence orders all reads and writes to the MPT for all supervisor domain address spaces.

• If rs1=x0 and rs2≠x0, the fence orders all reads and writes to the MPT for the supervisor domain address space identified by the SDID in rs2.

• If rs1≠x0 and rs2=x0, the fence orders all reads and writes made to the MPT that correspond to the physical address in rs1, for all supervisor domain address spaces.

• If rs1≠x0 and rs2≠x0, the fence orders all reads and writes made to the MPT that correspond to the physical address in rs1, for the supervisor domain address space identified by the SDID in rs2.

Executing a MFENCE.SPA guarantees that any previous stores already visible to the current hart are ordered before all implicit reads by that hart done for supervisor domain access-permission structures for non-M-mode instructions that follow the MFENCE.SPA.

When SDID is specified in rs2, bits XLEN-1:SDIDMAX held in rs2 are reserved for future standard use. Until their use is specified, they should be zeroed by software and ignored by implementations. Also, if SDIDLEN < SDIDMAX, the implementation shall ignore bits SDIDMAX-1:SDIDLEN of the value held in rs2.

Note	A simpler implementation of MFENCE.SPA may ignore the physical address in rs1, and/or the SDID value in rs2, and always perform a global fence for all SDs.

M-mode Supervisor Domain Fine-Grain Invalidation Instruction

In some high-performance implementations, a finer-granular invalidation and fencing is required that allows for synchronization operations to be more efficiently batched. When Svinval is implemented with Smsdid, the MINVAL.SPA instruction must be implemented to support such fine-granular invalidation of physical memory access-permission caches.

MINVAL.SPA instruction

{reg: [
  {bits:  7, name: 'opcode (SYSTEM)'},
  {bits:  5, name: 'rd (0)'},
  {bits:  3, name: 'func3 (PRIV)'},
  {bits:  5, name: 'rs1 (PADDR)'},
  {bits:  5, name: 'rs2 (SDID)'},
  {bits:  7, name: 'func7 (MINVAL.SPA)'},
], config:{lanes: 1, hspace:1024}}

MINVAL.SPA is only ordered against SFENCE.W.INVAL and SFENCE.INVAL.IR instructions. As part of the update to the SD access-permissions, the RDSM must ensure that it uses SFENCE.W.INVAL to guarantee that any previous stores to structures that hold supervisor domain access-permissions (e.g. MPT) are made visible before invoking the MINVAL.SPA. The RDSM must then use SFENCE.INVAL.IR to guarantee that all subsequent implicit references to supervisor domain access-permission structures (e.g. MPT) are ordered to be after the SD access-permissions cache invalidation. When executed in order (but not necessarily consecutively) by a single hart, the sequence SFENCE.W.INVAL, MINVAL.SPA and SFENCE.INVAL.IR has the same effect as a hypothetical MFENCE.SPA in which:

• the values of rs1 and rs2 for the MFENCE.SPA are the same as those used in the MINVAL.SPA,

• reads and writes prior to the SFENCE.W.INVAL are considered to be those prior to the MINVAL.SPA, and

• reads and writes following the SFENCE.INVAL.IR are considered to be those subsequent to the MFENCE.SPA

MINVAL.SPA is only valid in M-mode.

Extension to behavior of SFENCE.VMA, HFENCE.GVMA and HFENCE.VVMA

The behavior of the SFENCE.VMA, HFENCE.GVMA and HFENCE.VVMA instructions are affected when the Smsdid extension is implemented.

When SFENCE.VMA is used within a supervisor domain, the virtual-address argument is a virtual address with either the ASID being a S/HS-level ASID (V=0), or a VS-level ASID (V=1).

For S/HS-level ASID, the virtual-address argument to SFENCE.VMA is a host virtual address within the current supervisor domain, and the ASID argument is a S/HS-level ASID within the current supervisor domain. The current supervisor domain is identified by the SDID field of the CSR mmpt, and the effective ASID can be considered the combination of the SDID and the S/HS-level ASID. The SFENCE.VMA orders stores only to this S/HS-level address-translation structures with subsequent S/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 SDID field of the CSR mmpt and the VMID field of CSR hgatp. The effective ASID within this virtual machine can be considered to be the combination of this SDID and VMID along 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 mmpt.SDID and the hgatp.VMID is the same as when the SFENCE.VMA executed.

For HFENCE.GVMA, the guest-physical address argument is within the context of the current virtual machine idenfied by the combination of the SDID field of the CSR mmpt and the VMID field of CSR hgatp. Executing an HFENCE.GVMA guarantees that any previous stores already visible to the current hart are ordered before all implicit reads by that hart done for G-stage address translation for instructions that follow the HFENCE.GVMA, and execute with the same mmpt.SDID and hgatp.VMID when HFENCE.GVMA executed.

For HFENCE.VVMA, the guest-virtual address argument is within the context of the current virtual machine identified by the combination of the ASID specified in the vsatp, the VMID field of CSR hgatp, and the SDID field of CSR mmpt. Executing an HFENCE.VVMA guarantees that any previous stores already visible to the current hart are ordered before all implicit reads by that hart done for VS-stage address translations for instructions that are subsequent to the HFENCE.VMMA and execute when hgatp.VMID and mmpt.SDID have the same setting as it did when HFENCE.VVMA executed.

Extension to behavior of Svinval

When Svinval is implemented with Smsdid the behavior of SINVAL.VMA is modified to also use the SDID from the CSR mmpt in addition to the ASID provided in SINVAL.VMA.

When the Hypervisor extension is also implemented, the behavior of HINVAL.VVMA and HINVAL.GVMA is modified to also use the SDID from the CSR mmpt in addition to the VMID provided in the HINVAL.GVMA or the ASID provided in HINVAL.VVMA.