described MTT lookup process

chapter4.adoc

@@ -2,7 +2,8 @@
 [[Smmtt]]
 == `Smmtt`: Hart MTT Extension
 
-=== Smmtt[34, 46, 56]rw
+[[Smmtt-rw]]
+=== 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
@@ -59,6 +60,7 @@ for the supervisor domain
 The `INFO` field depends on the `TYPE` field and is formatted as per the
 following table:
 
+[[Smmtt-rw-l2-encoding]]
 .`MTTL2` Entry Type for Smmtt
 [width="100%",cols="25%,75%",options="header",]
 |===
@@ -74,7 +76,6 @@ _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` a|
 _The 1G range of address is allowed (read/write) for the domain._
@@ -123,12 +124,13 @@ domain
 ], config:{lanes: 1, hspace:1024}}
 ....
 
-=== Smmtt[34, 46, 56]
+[[Smmtt-ad]]
+=== 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
+Smmtt[34 | 46 | 56], each page is associated with an access allowed/disallowed
 permission (1 bit) to allow for efficient caching.
 
 [caption="Figure {counter:image}: ", reftext="Figure {image}"]
@@ -168,7 +170,8 @@ The `TYPE` field determines the interpretation of the `MTTL2` entry. The
 
 The `INFO` field depends on the `TYPE` field and is formatted as per the table:
 
-.`MTTL2` Entry for Smmtt[34, 46, 56]
+[[Smmtt-ad-l2-encoding]]
+.`MTTL2` Entry for Smmtt[34 | 46 | 56]
 [width="100%",cols="25%,75%",options="header",]
 |===
 |*`MTTL2` Entry Type* |*Description, `INFO` and `TYPE` field encoding*
@@ -221,9 +224,81 @@ follows:
 ], 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[rw]`, _LEVELS_ = 2 and for `Smmtt[46 | 56][rw]` LEVELS = 3; _PAGESIZE_
+is 2^12; MTT _NON_LEAF_PTE_SIZE_ = 8 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_ field 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
+<<Smmtt-rw-l2-encoding>> and <<Smmtt-ad-l2-encoding>>, 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 specifies it holds the access-permission
+encoding for 1GB pages per <<Smmtt-rw-l2-encoding>> and <<Smmtt-ad-l2-encoding>>
+; go to step 7, else
+
+* if _i_=1, and the _mpte.type_ field specifies it holds the access-permission
+encoding for 2MB pages; the _mpte.info_ field contains the access-permission
+encoding per <<Smmtt-rw-l2-encoding>> and <<Smmtt-ad-l2-encoding>>; go to
+step 7, else
+
+* If _i_=0, the _mpte_ contains a 2-bit entry for mode `Smmtt[34 | 46 | 56]`
+that holds the access-permission encodings (or 4-bit entry for mode
+`Smmtt[34 | 46 | 56]rw`) for 4KB pages. The 2/4-bit access-permission encoding
+for the PA is held in the ppn referenced by _mpte.info_ and indexed via
+_pa.pn[i]_. The encodings are specified in <<Smmtt-rw>> and <<Smmtt-ad>> for the
+`Smmtt[34 | 46 | 56]` and `Smmtt[34 | 46 | 56]rw` modes respectively.
+
+7. Determine if the requested physical memory access is allowed per the
+access-permissions. If access is not permitted, stop and raise a page-fault
+exception corresponding to the original access type. For modes
+`Smmtt[34 | 46 | 56]`, access-allowed implies read, write and execute
+permissions. For modes `Smmtt[34 | 46 | 56]rw`, read access implies read and
+execute, and read-write permission implies read and write (but no execute).
+
+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]
+====
+Implementations may cache any translation (due to 1st stage and/or G-stage
+translation) and access-permissions for the final (leaf) physical address
+being accessed - in this case, the `MTT`-derived access-permissions are
+AND'ed to accumulate the effective read, write, and execute permissions. Thus,
+MTT access-permissions can only further restrict access, and never grant
+permission denied by 1st-stage or G-stage translations.
+====
+
 === Access Enforcement and Fault Reporting
 
-As shown in <<mtt-lookup>>, MTT lookup composes with, but does not require,
+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