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. |
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) 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) 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.
mmptMODE field for XLEN=32.
| Value | Name | Description |
|---|---|---|
0 |
|
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 |
|
Page-based supervisor domain protection for up to 34 bit physical addresses with RWX permissions per page |
2-3 |
- |
|
mmptMODE field for XLEN=64.
| Value | Name | Description |
|---|---|---|
0 |
|
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 |
|
Page-based supervisor domain protection for up to 46 bit physical addresses with RWX permissions per page |
2 |
|
Page-based supervisor domain protection for up to 56 bit physical addresses with RWX permissions per page |
3-15 |
- |
|
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
in Register 1 and Register 2.
mmpt.PPN refers to an MPTL3 table or an MPTL2 table based on MODE. The
top-level MPT may be smaller than the size given in [Smmpt-rw] for that table
level, provided that it contains enough entries to cover the platform’s
physical address width (PAW), which is the number of bits needed to express
the platform-defined maximum-addressable physical address.
For PAW >= 56 a top-level MPTL3 table must be complete; for 56 > PAW >=
46 the table must contain at least 2^(PAW-46) entries; otherwise it must
contain at least one entry. For PAW >= 46 (34 for Smmpt34) a top-level
MTTL2 table must be complete; otherwise for PAW >= 25 the table must
contain at least 2^(PAW-25) entries; otherwise it must contain at least one
entry. The top-level table must be naturally aligned to its size, or aligned to
a 4 KiB page boundary, whichever is greater.
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.
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:
-
Smsdiausesmsdcfg.SDICNto specify the active configuration for the supervisor domain interrupt controller associated with the hart. -
Smsdedbgspecifies themsdcfg.sdedbgalwbit to manage external-debug for a supervisor domain. -
Smsdetrcspecifies themsdcfg.sdetrcalwbit to manage external-trace for a supervisor domain. -
Smqosidspecifies the control bitsSSM,SRL,SMLandSQRIDto 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}}
{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 the address in rs1 corresponds to an MPT_L1_DIR mapping, the fence applies to
a 4 KiB page. If the address in rs1 corresponds to a 2M_PAGES or 4M_PAGES mapping,
the fence applies to a 2 MiB or 4 MiB range. If the address in 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. |
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.
{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.SPAare the same as those used in theMINVAL.SPA, -
reads and writes prior to the
SFENCE.W.INVALare considered to be those prior to theMINVAL.SPA, and -
reads and writes following the
SFENCE.INVAL.IRare considered to be those subsequent to theMFENCE.SPA
MINVAL.SPA is only valid in M-mode.
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.
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.