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 mttp. 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 mttp 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 tracking table
(MTT), 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 (MTT Mode to be enforced) for physical
addresses. The MTT 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 mttp while executing in U, S or HS-mode will raise
an illegal instruction exception.
mttp) 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}}
mttp) 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 mttp MODE field for XLEN=32. shows the encodings of the MODE field when XLEN=32 and
Encoding of mttp MODE field for XLEN=64. shows the encodings of the MODE field when XLEN=64. When mttp
MODE=Bare, supervisor physical addresses have no MTT-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 mttp must be set to
zeros, else generate a fault. When XLEN=32, the other valid setting for
MODE is Smmtt34 to support allow/disallow and read-write-execute
access permissions for 34-bit system physical addresses.
When XLEN=64, other than BARE, the other valid settings for MODE are
Smmtt[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 mttp.
mttpMODE 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 34 bit physical addresses with RWX permissions per page |
2 |
- |
|
mttpMODE 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 46 bit physical addresses with RWX permissions per page |
2 |
|
Page-based supervisor domain protection for 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 mttp with an unsupported MODE value is not ignored.
Instead, the fields of mttp are WARL in the normal way, when so indicated.
The MTTPPN refers to an MTTL3 table or an MTTL2 table based on physical
address width (PAW). For 56 >= PAW > 46, MTTL3 table must be of size
2^(PAW-43) bytes and naturally aligned to that sized byte boundary. For 46
>= PAW > 32 the MTTL2 table must be of size 2^(PAW-22) bytes for
Smmtt46 and Smmtt34, and must be naturally aligned to that sized byte
boundary. In these modes, the lowest two bits of the physical page number
(MTTPPN) in mttp 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 mttp
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 Smmtt[34 | 46 | 56].
The mttp register is considered active for the purposes of the physical
address protection algorithm unless the effective privilege mode is M.
Note that writing mttp does not imply any ordering constraints between
S-mode and G-stage page-table updates and subsequent address translations.
If a supervisor domain’s MTT structure has been modified, or if a SDID is
reused, it may be necessary to execute a MFENCE.SPA instruction before or
after writing mttp.
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. 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 Sinval 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. MTT) 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. MTT) 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.