The Supervisor Physical Address (SPA) for RV32 and RV64 is shown below. The MPT 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 MPT is shown below. Figure 3
specifies an RV64 supervisor physical address lookup and Figure 4
specifies an RV32 supervisor physical address lookup. Each physical-addressable
page is associated with an access-permission encoding. The supervisor physical
address (SPA) is used to index into the MPT structure in memory to lookup
access permissions for the supervisor domain specified via the MPT structures.
Intermediate MPTL3 and MPTL2 non-leaf entries are used to allow this
structure to be sparsely populated. The MPTL3 table is not applicable for
physical address widths <= 46.
MPT walk for RV64
MPT walk for RV32The following MPT L3 entry accomodates a 56 bit PAW:
MPTL3 entry (XLEN=64 only){reg: [
{bits: 44, name: 'MPTL2 PPN'},
{bits: 1, name: 'VALID'},
{bits: 19, name: 'RESERVED'},
], config:{lanes: 1, hspace:1024}}
The VALID bit determines the validity of the MPTL3 entry. If this bit is
set, the MPTL3 entry is valid and the MPTL2 PPN holds the next level of the
MPT, and the RESERVED field must be 0. If the VALID bit is clear, the entry
is invalid, and all other bits in the entry are don’t-cares and may be used
freely by software.
The following are the MPTL2 entry by XLEN:
MPTL2 entry (XLEN=64){reg: [
{bits: 44, name: 'INFO'},
{bits: 3, name: 'TYPE'},
{bits: 17, name: 'RESERVED'},
], config:{lanes: 1, hspace:1024}}
MPTL2 entry (XLEN=32){reg: [
{bits: 22, name: 'INFO'},
{bits: 3, name: 'TYPE'},
{bits: 7, name: 'RESERVED'},
], config:{lanes: 1, hspace:1024}}
The RESERVED field must always be 0.
The TYPE field determines the interpretation of the MPTL2 entry. Unless
specified, the encodings are the same for RV32 and RV64. 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 -
MPT_L1_DIR- The 32 MiB range is composed of 8192 x 4 KiB pages. -
101b -
4M_PAGES(RV32) or2M_PAGES(RV64). For RV32,4M_PAGESspecifies that the 32 MiB range is composed of 8 x 4 MiB pages. For RV642M_PAGESspecifies that the 32 MiB range is composed of 16 x 2 MiB pages. -
110b -
Reservedfor future use and causes an access violation if used. -
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:
MPTL2 Entry Type for Smmpt
MPTL2 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 is specified as follows for RV32:
The 32 MiB range of address space is partitioned into 8 4 MiB pages where each
page has read/write/execute access specified via the |
|
This encoding is specifies as follows for RV64:
The 32 MiB range of address space is partitioned into 16 2 MiB pages where each
page has read/write/execute access specified via the |
The MPTL1 table is populated if protection granularity of the 4 KiB page is
desired for the supervisor domain.
The MPTL1 entry is XLEN wide and holds XLEN/4 number of 2-bit fields where
each field specifies the access-permissions for a 4 KiB page (with XLEN-1:XLEN/2
bits reserved for future use). The entry is selected by page.pn[1], and the
2-bit field in the entry is selected using page.pn[0]. 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:
MPTL1 Entry permission encoding
MPTL1 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. |
MPTL1 entry (XLEN=64){reg: [
{bits: 2, name: 'PERM'},
{bits: 28, name: '...'},
{bits: 2, name: 'PERM'},
{bits: 32, name: 'resv'},
], config:{lanes: 1, hspace:1024}}
MPTL1 entry (XLEN=32){reg: [
{bits: 2, name: 'PERM'},
{bits: 12, name: '...'},
{bits: 2, name: 'PERM'},
{bits: 16, name: 'resv'},
], config:{lanes: 1, hspace:1024}}
MPT access-permissions for a physical address PA in the context of a supervisor domain are ascertained as follows:
-
Let a be
mmpt.ppnx PAGESIZE, and let i = LEVELS, where for modeSmmpt[34 | 46], LEVELS = 2 and forSmmpt56, LEVELS = 3; PAGESIZE is 212; MPT_PTE_SIZE = 8 bytes (for RV32, MPT_PTE_SIZE = 4 bytes). Themmptregister must be active, i.e., the effective privilege mode must not be M-mode. -
If pa is greater than maximum-addressable physical address under the current MPT mode, or is greater than a platform-defined maximum-addressable physical address for the hart, then stop and raise an access-fault exception corresponding to the original access type.
-
Let mpte be the value of the
MPTtable entry at address a + pa.pn[i] x MPT_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, or mpte is a not-valid
MPTL3entry, stop and raise an access-fault exception corresponding to the original access type. -
Otherwise, the mpte is valid. If (i=1) or (i=2 and mpte.type is not
MPT_L1_DIR), go to step 6. Otherwise, the mpte is a pointer to the next level of theMPT. Let i = i-1. Let a = mpte.ppn x PAGESIZE and go to step 3. Note that when mpte.type =MPT_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
MPTL2Entry Type for Smmpt, 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=2, and the mpte.type field directly specifies the access-permissions for 1 GiB page regions (via 32 MPTL2 entries with identical mpte.type values - see
MPTL2Entry Type for Smmpt); go to step 8, else -
if i=2, 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 - seeMPTL2Entry Type for Smmpt; go to step 8, else -
if i=1, the mpte contains XLEN/4 2-bit entries that hold access-permission encodings for 4 KiB pages. The entry is selected by pa.pn[0]. The LSB XLEN/2-1:0 bits holds 2-bit encodings within the entry to specify the access-permission encoding for the pa. The MSB XLEN-1:XLEN/2 bits are reserved. The encodings are specified in
MPTL1Entry 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
MPTlookup.
All implicit accesses to the MPT data structures in
this algorithm are performed using width MPT_PTE_SIZE.
|
Note
|
Restricting the pa (in step 2) to the maximum-addressable PA width supported by a platform allows for optimizing memory requirements of the MPT structures such as the MPTL2 and MPTL3 entry tables, when the PA width is not 34, 46, or 56 bits. |
|
Note
|
MPT 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 [mpt-lookup], and described in the MPT lookup process,
MPT 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. MPT 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.
MPT 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 implicit MPT checker accesses to MPT structures. 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 MPT checks. MPT checker accesses to MPT structures are to be
treated as implicit M-mode accesses and are subject to PMP/Smepmp and
IOPMP checks. Implicit accesses to the MPT are governed by mstatus.MBE control
for RV64 and mstatush.MBE control for RV32. The MPT checker indexes the MPT 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
MPT 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 MPT supports configuration at supported architectural
page sizes. MPT violations manifest as instruction, load, or store access-fault
exceptions. The exception conditions for MPT 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 Smmpt is implemented, an MPT structure is used to specify
access-permissions for physical memory for a supervisor domain, the MPT
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. Therefore, when the MPT settings
are modified, M-mode software must synchronize the cached MPT state with the
virtual memory system and any PMP, MPT or address-translation caches, as
described via [mfence-spa] or in a batched manner via [minval-spa].
When used with the MPT, the MFENCE.SPA is used to synchronize updates to
in-memory MPT structures with current execution. MFENCE.SPA in this case,
applies only to the MPT data structures controlled by the
CSR mmpt. 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 MPT 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
|
MPT lookups that began while |
If mmpt.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.