The Supervisor Physical Address (SPA) for RV32 and RV64 is shown below. The MTT maps the SPA to read-write-execute access permissions.
{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}}
{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.
MTT walk for RV64
MTT walk for RV32The 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 -
Reservedfor 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:
MTTL2 Entry Type for Smmtt
MTTL2 Entry TYPE |
Description, INFO and TYPE field encoding |
|---|---|
|
read, write or execute is not allowed to this 1 GiB address range for the
domain. The |
|
read and execute (but no write) is allowed to this 1 GiB address range for the
domain. The |
|
read and write (but no execute) is allowed to this 1 GiB address range for the
domain. The |
|
read, write and execute is allowed to this 1 GiB address range for the domain.
The |
|
The |
|
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 |
|
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 |
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:
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 for a physical address PA in the context of a supervisor domain is ascertained as follows:
-
Let a be
mttp.ppnx PAGESIZE, and let i = LEVELS, where for modeSmmtt34, LEVELS = 2 and forSmmtt[46 | 56], LEVELS = 3; PAGESIZE is 212; MTT NON_LEAF_PTE_SIZE = 8 bytes (for RV32, MTT NON_LEAF_PTE_SIZE = 4 bytes). Themttpregister must be active, i.e., the effective privilege mode must be not-M-mode. -
Let mpte be the value of the
MTTtable 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. -
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.
-
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 theMTT. 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. -
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
MTTL2Entry Type for Smmtt, are set within mpte, stop and raise an access-fault exception corresponding to the access type. -
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
MTTL2Entry 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 of4M_PAGES, the mpte.info[16:0] field contains 8 entries of 2-bit access-permission encodings for 8 4 MiB regions - seeMTTL2Entry 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
MTTL1Entry permission encoding.
-
-
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.
-
The access is allowed per the
MTTlookup.
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. |
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.
[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 |
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.