Skip to content

Latest commit

 

History

History
291 lines (243 loc) · 11.7 KB

chapter4.adoc

File metadata and controls

291 lines (243 loc) · 11.7 KB
Raw

Smmtt: Hart MTT Extension

Smmtt[34, 46, 56]rw

The PPN rooted structure for the MTT is shown below. The structure below shows a 56 bit physical address lookup; for lower physical address widths e.g. 46 bits, the MTTL3 table is not applicable. In this mode of the Smmtt[34, 46, 56]rw, each page is associated with a read and a write access permission (2 bits). Figure 1 shows the Physical address (PA) being used to index into the MTT structure in memory to lookup access permissions for the supervisor domain specified in the MTTL1 entry. Intermediate MTTL3 and MTTL2 entries are used to allow this structure to be sparsely populated.

fig3
Figure 1: MTT Structures (overview)

The following MTT L2/L3 entries accomodate a 56 bit PAW.

MTTL3 entry
{reg: [
  {bits:  44, name: 'MTTL2 PPN'},
  {bits:  20, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}
MTTL2 entry
{reg: [
  {bits:  44, name: 'INFO'},
  {bits:  4, name: 'TYPE'},
  {bits:  16, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}

The ZERO field must always be 0.

The TYPE field determines the interpretation of the MTTL2 entry. The TYPE field encoding is as follows:

  • 0000b - 1G_disallow - read and write access is not allowed for the 1G range for this supervisor domain

  • 0001b - 1G_allow_r - read access for the 1G range is allowed for the supervisor domain

  • 0011b - 1G_allow_rw - read and write access for the 1G range is allowed for the supervisor domain

  • 0100b - MTT_L1_DIR - The 32M range is composed of 8192x4K pages

  • 0111b - 2M_PAGES - The 32M range is composed of 16x2M pages

  • All other encodings are reserved and cause an access violation

The INFO field depends on the TYPE field and is formatted as per the following table:

Table 1. MTTL2 Entry Type for Smmtt
MTTL2 Entry TYPE Description, INFO and TYPE field encoding

1G_disallow

The 1G range of address is not allowed for the domain. The INFO field must be 0. When configuring 1G ranges, RDSM ensures that 32 MTTL2 entries, each corresponding to 32M of address space, have identical TYPE field values.

1G_allow_r

The 1G range of address is allowed (read only) for the domain. The INFO field must be 0. When configuring 1G ranges, RDSM ensures that 32 MTTL2 entries, each corresponding to 32M of address space, have identical TYPE field values. The INFO field must be 0.

1G_allow_rw

The 1G range of address is allowed (read/write) for the domain. The INFO field must be 0. When configuring 1G ranges, RDSM ensures that 32 MTTL2 entries, each corresponding to 32M of address space, have identical TYPE field values.

MTT_L1_DIR

The INFO field provides the PPN of the MTTL1 page. Entries of the MTTL1 page hold a 4-bit PERM (permissions) field to indicate the access for the supervisor domain (described in the MTTL1 entry Figure 4).

2M_PAGES

The 32M range of address space is partitioned into 2M pages where each page has read/write access allowed/not. The INFO field 31:0 holds 2 PERM bits per 2M address range to indicate access_disallowed (00b), read_allowed (01b), read_write_allowed (11b); (10b is reserved). Bits 32:43 are reserved and must be zero.

MTTL1 table is populated if protection granularity of the 4KiB page is desired for the supervisor domain.

MTTL1 entry is indexed using PA[24:12] and each entry is a 4-bit PERM field in the referenced page. The bits 24:16 are used to select a 64-bit field in the page and bits 15:12 are used to select a 4 bit PERM field in those 64 bits. Thus, there are 4 PERM bits for each 4 KiB page. The encoding of PERM is as follows:

  • 0000b - the 4K page specifies access is not allowed for the domain

  • 0001b - the 4K page specifies read access is allowed for the domain

  • 0011b - the 4K page specifies read and write access is allowed for the domain

  • Remaining encodings are reserved and cause an access violation.

MTTL1 entry
{reg: [
  {bits:  4, name: 'PERM'},
  {bits:  56, name: '...'},
  {bits:  4, name: 'PERM'},
], config:{lanes: 1, hspace:1024}}

Smmtt[34, 46, 56]

The PPN rooted structure for the MTT is shown below. The structure below shows a 56 bit physical address lookup; for lower physical address widths e.g. 46 bits, the L3 table is not applicable. In this mode of the Smmtt[34, 46, 56], each page is associated with an access allowed/disallowed permission (1 bit) to allow for efficient caching.

fig4
Figure 5: MTT Structures (overview)
MTTL3 entry
{reg: [
  {bits:  44, name: 'MTTL2 PPN'},
  {bits:  20, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}
MTTL2 entry
{reg: [
  {bits:  44, name: 'INFO'},
  {bits:  2, name: 'TYPE'},
  {bits:  18, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}

The ZERO field must always be 0.

The TYPE field determines the interpretation of the MTTL2 entry. The TYPE field encoding is as follows:

  • 00b - 1G_disallow - access to the 1G range is disallowed

  • 01b - 1G_allow - access to the 1G range is allowed

  • 10b - MTT_L1_DIR - The 64M range is composed of 16384x4K pages

  • 11b - 2M_PAGES - The 64M range is composed of 32x2M pages

The INFO field depends on the TYPE field and is formatted as per the table:

Table 2. MTTL2 Entry for Smmtt[34, 46, 56]
MTTL2 Entry Type Description, INFO and TYPE field encoding

1G_allow

The 1G range of address is allowed for the domain. The INFO field must be 0. When configuring 1G ranges, RDSM ensures that 16 MTTL2 entries, each corresponding to 64M of address space, have identical TYPE field values.

1G_disallow

The 1G range of address is not allowed for the domain. The INFO field must be 0. When configuring 1G ranges, RDSM ensures that 16 MTTL2 entries, each corresponding to 64M of address space, have identical TYPE field values.

MTT_L1_DIR

The INFO field provides the PPN of the MTTL1 page. Entries of the MTTL1 page hold a 2-bit PERM field to indicate the access for the supervisor domain (described in the MTTL1 entry Figure 8).

2M_PAGES

The 64M range of address space is partitioned into 2M pages where each page has access allowed/not. The INFO field bits 31:0 holds 1 bit per 2M address range to indicate access disallowed(0b) or allowed (1b). INFO field bits 43:32 are reserved (must be zero).

MTTL1 table is populated if 4KiB page confidential pages are required for the supervisor domain.

MTTL1 entry is indexed using PA[25:12] and each entry is a 2-bit PERM field in the referenced page. The bits 25:16 are used to select a 64-bit field in the page and bits 16:12 are used to select a 2 bit PERM field in those 64 bits. Thus, there are 2 PERM bits for each 4 KiB page. The encoding is as follows:

  • 00b - the 4K page specifies access is not allowed for the domain

  • 01b - the 4K page specifies access is allowed for the domain

  • 1xb - reserved (access causes access violation).

MTTL1 entry
{reg: [
  {bits:  2, name: 'PERM'},
  {bits:  60, name: '...'},
  {bits:  2, name: 'PERM'},
], config:{lanes: 1, hspace:1024}}

Access Enforcement and Fault Reporting

As shown in [mtt-lookup], MTT lookup composes with, but does not require, page-based virtual memory (MMU, IOMMU) and physical memory protection mechanisms (PMP, Smepmp, IOPMP). When paging is enabled, instructions that access virtual memory may result in multiple physical-memory accesses, including (implicit S-mode) accesses to the page tables. MTT checks also apply to these implicit S-mode accesses - those accesses will be treated as reads for translation and as writes when A/D bits are updated in page table entries when Svadu is implemented.

MTT is checked for all accesses to physical memory, unless the effective privilege mode is M, including accesses that have undergone virtual to physical memory translation, but excluding MTT structure accesses. Data accesses in M-mode when the MPRV bit in mstatus is set and the MPP field in mstatus contains S or U are subject to MTT checks. MTT structure accesses are to be treated as implicit M-mode accesses and are subject to PMP/Smepmp and IOPMP checks. The MTT checker indexes the MTT using the physical address of the access to lookup and enforce the access permissions. A mismatch of the access type and the access permissions specified in the MTT entry that applies to the accessed region is reported as a trap to the RDSM which may report it to a supervisor domain. To enable composing with Sv modes, the MTT supports configuration at supported architectural page sizes. MTT violations manifest as instruction, load, or store access-fault exceptions. The exception conditions for MTT are checked when the access to memory is performed.

Caching of MTT and Supervisor Domain Fence Instruction

[mfence-spa] describes the canonical behavior of the MFENCE.SPA instruction to invalidate cached access-permissions for all supervisor domains, a specific supervisor domain, or a specific physical address for a supervisor domain.

[minval-spa] implemented with Sinval describes a finer granular invalidation of access-permission caches.

When Smmtt is implemented, an MTT structure is used to specify access-permissions for physical memory for a supervisor domain, the MTT settings for the resulting physical address (after any address translation) may be checked (and possibly cached) at any point between the address translation and the explicit memory access. If caching is occuring, when the MTT settings are modified, M-mode software must synchronize the cached MTT state with the virtual memory system and any PMP, MTT or address-translation caches, as described via [mfence-spa] or in a batched manner via [minval-spa].

When used with the MTT, the MFENCE.SPA is used to synchronize updates to in-memory MTT structures with current execution. MFENCE.SPA in this case, applies only to the memory tracking table data structures controlled by the CSR mttp. 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 the MTT for non-M-mode instructions that follow the MFENCE.SPA.

When MINVAL.SPA is used, access-permission cache synchronization may be batch optimized via the use of the sequence SFENCE.W.INVAL, MINVAL.SPA and SFENCE.INVAL.IR.

Note

MTT lookups that began while mttp was active are not required to complete or terminate when mttp is no longer active, unless a MFENCE.SPA instruction matches the SDID (and optionally, PADDR) is executed. The MFENCE.SPA instruction must be used to ensure that updates to the MTT data structures are observed by subsequent implicit reads to those structures by a hart.

If mttp.MODE is changed for a given SDID, a MFENCE.SPA with rs1=x0 and rs2 set either to x0 or the given SDID, must be executed to order subsequent PA access checks with the MODE change, even if the old or new MODE is Bare.