Smsdid defines an interface to program the configuration for
supervisor-domain-related extensions. The interface consists of M-mode CSRs
msdcfg and mmpt. When Smsdid is implemented, both CSRs must be
implemented; msdcfg may be read-only zero if none of the optional supervisor
domain extensions are implemented.
The SDID programmed via the mmpt CSR 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
the SDID must not be used to tag downstream transactions that are globally
visible.
|
Note
|
For most typical usages, the |
The mmpt register is an MXLEN wide read/write machine-mode register,
formatted as shown in Register 1 for MXLEN=32 and Register 2 for MXLEN=64,
which controls page-based physical address space protection. This register holds
the supervisor domain identifier (SDID); the physical page number (PPN) of
the root page of the memory protection tables (MPT), which facilitates
page-based address space protection; and the MODE field, which selects the
memory protection scheme for physical addresses. The CSR number for mmpt is
0x382.
mmpt) when MXLEN=32.{reg: [
{bits: 22, name: 'PPN (WARL)'},
{bits: 6, name: 'SDID (WARL)'},
{bits: 2, name: '0 (WARL)'},
{bits: 2, name: 'MODE (WARL)'},
], config:{lanes: 2, hspace:1024}}
mmpt) when MXLEN=64.{reg: [
{bits: 44, name: 'PPN (WARL)'},
{bits: 8, name: '0 (WARL)'},
{bits: 6, name: 'SDID (WARL)'},
{bits: 2, name: '0 (WARL)'},
{bits: 4, name: 'MODE (WARL)'},
], config:{lanes: 2, hspace:1024}}
The number of implemented 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.
Encoding of mmpt MODE field for MXLEN=32. shows the encodings of the MODE field when MXLEN=32 and
Encoding of mmpt MODE field for MXLEN=64. shows the encodings of the MODE field when MXLEN=64.
mmptMODE field for MXLEN=32.
| Value | Name | Description |
|---|---|---|
0 |
|
No page-based memory protection beyond the physical memory
protection scheme described in Section 3.7 of the RISC-V privileged architecture
specification cite:[ISA]. The remaining fields in |
1 |
|
Page-based memory protection for up to 34-bit physical address spaces. |
2 |
- |
|
3 |
- |
|
mmptMODE field for MXLEN=64.
| Value | Name | Description |
|---|---|---|
0 |
|
No page-based memory protection beyond the physical memory
protection scheme described in Section 3.7 of the RISC-V privileged architecture
specification cite:[ISA]. The remaining fields in |
1 |
|
Page-based memory protection for up to 43-bit physical address spaces. |
2 |
|
Page-based memory protection for up to 52-bit physical address spaces. |
3 |
|
Page-based memory protection for up to 64-bit physical address spaces. |
4-13 |
- |
|
14-15 |
- |
|
Implementations are not required to support all defined MODE settings. 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 the root of the memory protection table when mmpt.MODE
is not Bare.
When mmpt.MODE is Smmpt64, the root page of the memory protection table must
be aligned to a 32 KiB boundary. In this mode, bits 2:0 of mmpt.PPN always read
as zero.
The mmpt register is considered active for the purposes of access type
permission lookup algorithm unless the effective privilege mode is M.
Note that writing mmpt does not imply any ordering constraint between
updates of virtual memory system page-tables or memory protection tables and
subsequent address translations or memory protection.
If an MPT structure for an address-space has been modified, or if a SDID is
reused, it may be necessary to execute a MFENCE.PA instruction after, or in
some cases before, writing mmpt.
{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.PA)'},
], config:{lanes: 1, hspace:1024}}
The MFENCE.PA fence instruction is used to synchronize updates to
memory protection tables with current execution of supervisor domains.
MFENCE.PA 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.
The behavior of MFENCE.PA depends on rs1 and rs2 as follows:
-
If
rs1=x0andrs2=x0, the fence orders all reads and writes to any level of the MPTs for all supervisor domain address spaces. -
If
rs1=x0andrs2!=x0, the fence orders all reads and writes to any level of the MPT for the supervisor domain address space identified by theSDIDinrs2. -
If
rs1!=x0andrs2=x0, the fence orders all reads and writes made to the leaf MPT entries that correspond to the physical address inrs1, for all supervisor domain address spaces. -
If
rs1!=x0andrs2!=x0, the fence orders all reads and writes made to the leaf MPT PTEs that correspond to the physical address inrs1, for the supervisor domain address space identified by theSDIDinrs2.
Executing a MFENCE.PA guarantees that any previous stores already visible to
the current hart are ordered before all implicit reads by that hart to memory
protection tables.
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 |
When Svinval and Smsdid are both implemented, the MINVAL.PA instruction
must be implemented. MINVAL.PA supports batching of MPT invalidations,
analogous to SINVAL.VMA.
{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.PA)'},
], config:{lanes: 1, hspace:1024}}
MINVAL.PA is only ordered against SFENCE.W.INVAL and SFENCE.INVAL.IR
instructions.
The SFENCE.W.INVAL instruction guarantees that any previous stores already
visible to the current RISC-V hart are ordered before subsequent MINVAL.PA
instructions executed by the same hart.
The SFENCE.INVAL.IR instruction guarantees that any previous MINVAL.PA
instructions executed by the current hart are ordered before subsequent
implicit references by that hart to memory-protection data structures.
When executed in order (but not necessarily consecutively) by a single hart,
the sequence SFENCE.W.INVAL, MINVAL.PA and SFENCE.INVAL.IR has the same
effect as a hypothetical MFENCE.PA in which:
-
the values of
rs1andrs2for theMFENCE.PAare the same as those used in theMINVAL.PA, -
reads and writes prior to the
SFENCE.W.INVALare considered to be those prior to theMINVAL.PA, and -
reads and writes following the
SFENCE.INVAL.IRare considered to be those subsequent to theMFENCE.PA
MINVAL.PA is only valid in M-mode.
The behavior of the SFENCE.VMA, HFENCE.GVMA, and HFENCE.VVMA instructions
is affected when the Smsdid extension is implemented. When the Svinval
extension is also implemented, the behavior of the SINVAL.VMA, HINVAL.GVMA,
and HINVAL.VVMA instructions is also affected.
The ASID and VMID arguments of these instructions correspond to the ASID`s
and `VMID`s that are active within the current supervisor domain, which is
identified by the `SDID field of the CSR mmpt. The SDID augments the ASID
and VMID values to form the effective identifiers used by these instructions.
An effective S/HS-level ASID can be considered to be the combination of the
SDID with the S/HS-level ASID. Likewise, an effective VS-level ASID can be
considered to be the combination of the SDID with the VS-level ASID.
An effective VMID can be considered to be the combination of the SDID with
the VMID.
The msdcfg is a MXLEN wide machine-mode read/write register, formatted as
shown in Register 3. This CSR is used to hold configurations for a supervisor
domain. The CSR number for msdcfg is 0x74E.
The following extensions specify the fields of the msdcfg register:
-
Smsdiaspecifies theSIDNfield to identify the supervisor interrupt domain associated with the hart. -
Smsdedbgaspecifies theSEDAbit to allow external-debug for supervisor domains. -
Smsdetrcaspecifies theSETAbit to allow external-trace for supervisor domains. -
Smsdqosidspecifies theSRL,SML,SSRM, andSSMMfields to determine supervisor domain QoS IDs.
Details of Smsdia, Smsdedbga, Smsdetrca, and Smsdqosid are described in
their respective sections in this specification. If an extension is not
implemented, the corresponding configuration bits in msdcfg are read-only
zero. Hence if no optional extensions are implemented, this CSR becomes
read-only zero.
msdcfg register {reg: [
{bits: 6, name: 'SIDN'},
{bits: 1, name: 'SEDA'},
{bits: 1, name: 'SETA'},
{bits: 14, name: 'WPRI'},
{bits: 1, name: 'SSRM'},
{bits: 1, name: 'SSMM'},
{bits: 4, name: 'SRL'},
{bits: 4, name: 'SML'},
], config:{lanes: 2, hspace:1600}}