Skip to content

Latest commit

 

History

History
284 lines (237 loc) · 11.3 KB

File metadata and controls

284 lines (237 loc) · 11.3 KB

Smsdid: Supervisor Domain Identifier and Protection Register

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 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 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 register (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 register (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.

Table 1. Encoding of mmptMODE field for MXLEN=32.
Value Name Description

0

Bare

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 mmpt (SDID, PPN) must be set to zeros.

1

Smmpt34

Page-based memory protection for up to 34-bit physical address spaces.

2

-

Reserved for future standard use.

3

-

Designated for custom use.

Table 2. Encoding of mmptMODE field for MXLEN=64.
Value Name Description

0

Bare

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 mmpt (SDID, PPN) must be set to zeros.

1

Smmpt43

Page-based memory protection for up to 43-bit physical address spaces.

2

Smmpt52

Page-based memory protection for up to 52-bit physical address spaces.

3

Smmpt64

Page-based memory protection for up to 64-bit physical address spaces.

4-13

-

Reserved for future standard use.

14-15

-

Designated for custom use.

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.

Machine Memory Protection Fence Instruction

MFENCE.PA 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.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=x0 and rs2=x0, the fence orders all reads and writes to any level of the MPTs for all supervisor domain address spaces.

  • If rs1=x0 and rs2!=x0, the fence orders all reads and writes to any level of 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 leaf MPT entries 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 leaf MPT PTEs that correspond to the physical address in rs1, for the supervisor domain address space identified by the SDID in rs2.

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 MFENCE.PA 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

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.

MINVAL.PA 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.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 rs1 and rs2 for the MFENCE.PA are the same as those used in the MINVAL.PA,

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

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

MINVAL.PA is only valid in M-mode.

Extension to Behavior of Memory-Management Fences

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.

Machine supervisor domain configuration (msdcfg)

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:

  1. Smsdia specifies the SIDN field to identify the supervisor interrupt domain associated with the hart.

  2. Smsdedbga specifies the SEDA bit to allow external-debug for supervisor domains.

  3. Smsdetrca specifies the SETA bit to allow external-trace for supervisor domains.

  4. Smsdqosid specifies the SRL, SML, SSRM, and SSMM fields 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}}