Skip to content

Latest commit

 

History

History
359 lines (305 loc) · 15.4 KB

chapter4.adoc

File metadata and controls

359 lines (305 loc) · 15.4 KB

Smmtt: Hart MTT Extension

Smmtt[34 | 46 | 56]

The Supervisor Physical Address (SPA) for RV32 and RV64 is shown below. The MTT maps the SPA to read-write-execute access permissions.

RV32 Supervisor Physical Address
{reg: [
  {bits:  12, name: 'page offset', attr: '12'},
  {bits:  3,  name: 'pn[0]',       attr: '3' },
  {bits:  10, name: 'pn[1]',       attr: '10' },
  {bits:  9,  name: 'pn[2]',       attr: '9'},
], config:{lanes: 1, hspace:1024}}
RV64 Supervisor Physical Address
{reg: [
  {bits:  12, name: 'page offset', attr: '12'},
  {bits:  4,  name: 'pn[0]',       attr: '4' },
  {bits:  9,  name: 'pn[1]',       attr: '9' },
  {bits:  21, name: 'pn[2]',       attr: '21'},
  {bits:  10, name: 'pn[3]',       attr: '10'},
], config:{lanes: 1, hspace:1024}}

The PPN rooted structure for the MTT is shown below. Figure 3 shows an RV64 supervisor physical address lookup; for lower physical address widths e.g. 34 or 46 bits, the MTTL3 table is not applicable as shown in Figure 4. Each physical-addressable page is associated with an access-permission encoding. The Supervisor Physical address (SPA) is used to index into the MTT structure in memory to lookup access permissions for the supervisor domain specified in the MTTL2 or MTTL1 entries. Intermediate MTTL3 and MTTL2 non-leaf entries are used to allow this structure to be sparsely populated.

fig3
Figure 3: MTT walk for RV64
fig3b
Figure 4: MTT walk for RV32

The following MTT L3 entry accomodates a 56 bit PAW:

MTTL3 entry (XLEN=64 only)
{reg: [
  {bits:  44, name: 'MTTL2 PPN'},
  {bits:  20, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}

The following are the MTTL2 entry by XLEN:

MTTL2 entry (XLEN=64)
{reg: [
  {bits:  44, name: 'INFO'},
  {bits:  3,  name: 'TYPE'},
  {bits:  17, name: 'ZERO'},
], config:{lanes: 1, hspace:1024}}
MTTL2 entry (XLEN=32)
{reg: [
  {bits:  22, name: 'INFO'},
  {bits:  3,  name: 'TYPE'},
  {bits:  7,  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:

  • 000b - 1G_disallow - read, write or execute access is not allowed for the 1 GiB range for the supervisor domain.

  • 001b - 1G_allow_rx - read and execute access for the 1 GiB range is allowed for the supervisor domain.

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

  • 011b - 1G_allow_rwx - read, write and execute access for the 1 GiB range is allowed for the supervisor domain

  • 100b - MTT_L1_DIR - The 32 MiB range is composed of 8192 x 4 KiB pages.

  • 101b - 4M_PAGES - The 32 MiB range is composed of 8 x 4 MiB pages. This encoding only applies to RV32 and is reserved for RV64.

  • 110b - 2M_PAGES - The 32 MiB range is composed of 16 x 2 MiB pages. This encoding only applies to RV64 and is reserved for RV32.

  • 111b - Reserved for future use and causes an access violation if used.

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

read, write or execute is not allowed to this 1 GiB address range for the domain. The INFO field must be 0. When configuring 1 GiB ranges, RDSM must ensure that 32 MTTL2 entries, each corresponding to 32 MiB of address space, have identical TYPE field values.

1G_allow_rx

read and execute (but no write) is allowed to this 1 GiB address range for the domain. The INFO field must be 0. When configuring 1 GiB ranges, RDSM must ensure that 32 MTTL2 entries, each corresponding to 32 MiB of address space, have identical TYPE field values.

1G_allow_rw

read and write (but no execute) is allowed to this 1 GiB address range for the domain. The INFO field must be 0. When configuring 1 GiB ranges, RDSM must ensure that 32 MTTL2 entries, each corresponding to 32 MiB of address space, have identical TYPE field values.

1G_allow_rwx

read, write and execute is allowed to this 1 GiB address range for the domain. The INFO field must be 0. When configuring 1 GiB ranges, RDSM must ensure that 32 MTTL2 entries, each corresponding to 32 MiB 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 XLEN/4 4-bit fields with 2-bit PERM field (bits 1:0) and 2 reserved bits (3:2) for future use. The 2-bit PERM field holds access-permission for 4 KiB pages for the supervisor domain, as described in Figure 8 for RV64 and Figure 9 for RV32.

2M_PAGES

This encoding applies only to RV64. The 32 MiB range of address space is partitioned into 16 2 MiB pages where each page has read/write/execute access allowed/not specified via the INFO field. The INFO field holds 16 2-bit PERM access-encoding for each 2 MiB address range to indicate: no_access_allowed (00b), read-execute-allowed (01b), read-write-allowed (10b), read-write-execute-allowed (11b). Bits mpte.info[31:0] holds the 2 MiB page permissions, and mpte.info[43:32] are reserved and must be zero.

4M_PAGES

This encoding applies only to RV32. The 32 MiB range of address space is partitioned into 8 4 MiB pages where each page has read/write/execute access allowed/not specified via the INFO field. The INFO field holds 8 2-bit PERM access-encoding for each 4 MiB address range to indicate: no_access_allowed (00b), read-execute-allowed (01b), read-write-allowed (10b), read-write-execute-allowed (11b). Bits mpte.info[15:0] holds the 2 MiB page permissions, and mpte.info[21:16] are reserved and must be zero.

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

The MTTL1 entry is XLEN wide and holds XLEN/4 number of 4-bit fields where each field specifies 2-bit access-permissions for a 4 KiB page (with 2 bits reserved for future uses). The entry is selected by page.pn[1], and the 4-bit field in the entry is selected using page.pn[0], with lsb bits 1:0 holding the access-permission encoding. See Figure 8 for XLEN = 64 and Figure 9 for XLEN = 32. Thus, there are 2 PERM bits for each 4 KiB page. The encoding of PERM is as follows:

Table 2. MTTL1 Entry permission encoding
MTTL1 Access-permission encoding Description

00b

The entry specifies access to the 4 KiB address space is not allowed for the domain.

01b

The entry specifies read and execute (but no write) access is allowed to the 4 KiB address space for the domain.

10b

The entry specifies read and write (but no execute) access is allowed to the 4 KiB address space for the domain.

11b

The entry specifies read, write and execute access is allowed to the 4 KiB address space for the domain.

MTTL1 entry (XLEN=64)
{reg: [
  {bits:  2, name: 'PERM'},
  {bits:  2, name: 'resv'},
  {bits:  56, name: '...'},
  {bits:  2, name: 'PERM'},
  {bits:  2, name: 'resv'},
], config:{lanes: 1, hspace:1024}}
MTTL1 entry (XLEN=32)
{reg: [
  {bits:  2, name: 'PERM'},
  {bits:  2, name: 'resv'},
  {bits:  24, name: '...'},
  {bits:  2, name: 'PERM'},
  {bits:  2, name: 'resv'},
], config:{lanes: 1, hspace:1024}}

MTT access permissions lookup process

MTT access-permissions for a physical address PA in the context of a supervisor domain is ascertained as follows:

  1. Let a be mttp.ppn x PAGESIZE, and let i = LEVELS, where for mode Smmtt34, LEVELS = 2 and for Smmtt[46 | 56], LEVELS = 3; PAGESIZE is 212; MTT NON_LEAF_PTE_SIZE = 8 bytes (for RV32, MTT NON_LEAF_PTE_SIZE = 4 bytes). The mttp register must be active, i.e., the effective privilege mode must be not-M-mode.

  2. Let mpte be the value of the MTT table entry at address a + pa.pn[i] x NON_LEAF_PTE_SIZE. If accessing mpte violates a PMA or PMP check, raise an access-fault exception corresponding to the original access type.

  3. If any bits or encodings that are reserved for future standard use are set within mpte, stop and raise an access-fault exception corresponding to the original access type.

  4. Otherwise, the mpte is valid. If (i=0) or (i=1 and mpte.type is not MTT_L1_DIR), go to step 5. Otherwise, the mpte is a pointer to the next level of the MTT. Let i = i-1. If i < 0, stop and raise an access-fault exception corresponding to the original access type. Otherwise, let a = mpte.ppn x PAGESIZE and go to step 2. Note that when mpte.type = MTT_L1_DIR, the mpte.ppn is the value of the mpte.info field.

  5. A leaf mpte has been found. If any bits or encodings within mpte.type and mpte.info that are reserved for future standard use, per MTTL2 Entry Type for Smmtt, are set within mpte, stop and raise an access-fault exception corresponding to the access type.

  6. The mpte is a valid leaf mpte. Fetch the access-permissions for the physical address per the steps described below:

    • if i=1, and the mpte.type field directly specifies the access-permissions for 1 GiB page regions (via 32 MTTL2 entries with identical mpte.type values - see MTTL2 Entry Type for Smmtt); go to step 7, else

    • if i=1, and for XLEN = 64 and the mpte.type field value 2M_PAGES, the mpte.info[31:0] field contains 16 entries of 2-bit access-permission encodings for 16 2 MiB address regions; For XLEN=32 and mpte.type field value of 4M_PAGES, the mpte.info[16:0] field contains 8 entries of 2-bit access-permission encodings for 8 4 MiB regions - see MTTL2 Entry Type for Smmtt; go to step 7, else

    • if i=0, the mpte contains XLEN/4 entries that holds access-permission encodings for 4 KiB pages. The 4-bit field has the lsb 2-bits specify the access-permission encoding for the pa (and 2 bits reserved) in the mpte is indexed via pa.pn[i]. The encodings are specified in MTTL1 Entry permission encoding.

  7. Determine if the requested physical memory access is allowed per the access-permissions. If access is not permitted, stop and raise an access-fault exception corresponding to the original access type.

  8. The access is allowed per the MTT lookup.

All implicit accesses to the non-leaf memory tracking table data structures in this algorithm are performed using width NON_LEAF_PTE_SIZE.

Note

MTT access-permissions can only further restrict access, and never grant read, write or execute permission denied by 1st-stage or G-stage translations.

Access Enforcement and Fault Reporting

As shown in [mtt-lookup], and described in the MTT lookup process, 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.