Merge pull request #105 from riscv/issue/91

Change name of MTT to MPT, mttp to mmpt, & ext. name from Smmtt to Smmpt

chapter2.adoc

@@ -14,20 +14,20 @@ levels and is held in a M-mode CSR. This extension may be
 used independently or may be combined with other extensions in this
 specification.
 
-* `Smmtt` (<<Smmtt>>) - An extension to set the access permissions for a memory
+* `Smmpt` (<<Smmpt>>) - An extension to set the access permissions for a memory
 region or page associated with a supervisor domain. This extension allows for
 dynamic changes of access permission. Such dynamic changes may require flushing of
-appropriate state cached in harts. The access properties are programmed via an Memory
-Tracking Table (MTT) structure. The physical page number (PPN) of the root table of
-the MTT is programmed into a M-mode CSR. When `Smmtt` is implemented, MTT
-and e(PMP) are always active. Although there is no option to disable MTT, it can be
+appropriate state cached in harts. The access properties are programmed via an Machine-level Memory
+Protection Tables (MPT) structure. The physical page number (PPN) of the root table of
+the MPT is programmed into a M-mode CSR. When `Smmpt` is implemented, MPT
+and e(PMP) are always active. Although there is no option to disable MPT, it can be
 effectively disabled if granular memory access control is not required by configuring
-MTT mode to be `Bare`.
+MPT mode to be `Bare`.
 
-* `IO-MTT` (<<IO-MTT>>) - A non-ISA extension that enables programming of an IO
+* `IO-MPT` (<<IO-MPT>>) - A non-ISA extension that enables programming of an IO
 interconnect to associate an IOMMU and devices in scope of that IOMMU with an SD. The
 assignment of IOMMUs to supervisor domains is also expected to be under the
-purview of the RDSM. IO-MTT extension specifies the memory access control mechanisms for
+purview of the RDSM. IO-MPT extension specifies the memory access control mechanisms for
 memory accesses performed by the IOMMU as well as by the devices associated with that SD.
 Note that isolation of data within a device is
 out of scope of this specification.

chapter3.adoc

@@ -4,31 +4,31 @@
 
 `Smsdid` defines an interface to program the active supervisor domain
 under which a hart is operating. The interface consists of M-mode CSRs `msdcfg`
-and `mttp`. The SDID programmed via this interface is a local identifier for the
+and `mmpt`. The SDID programmed via this interface is a local identifier for the
 hart and may be used to tag hart-local resources to access-control data
 associated with the supervisor domain. For most typical usages, the SDID will
 remain stable over the life of the supervisor domain. However, the SDID can be
 changed at the cost of fencing to flush any prior cached state. The SDID is
 unique only to a hart, hence, SDID must not be used to tag downstream
 transactions that are globally visible.
 
-=== Machine tracking table pointer (`mttp`)
+=== Machine-level Memory Protection Tables (`mmpt`)
 
-The `mttp` register is an `XLEN`-bit read/write register, formatted as shown in
+The `mmpt` register is an `XLEN`-bit read/write register, formatted as shown in
 <<sdid-32>> for `XLEN=32` and <<sdid-64>> for `XLEN=64`, which controls
 physical address protection for supervisor domains. This register holds the
-physical page number (`PPN`) of the root page of the memory tracking table
-(`MTT`), a supervisor domain identifier (`SDID`), which facilitates address
+physical page number (`PPN`) of the root page of the memory protection tables
+(`MPT`), a supervisor domain identifier (`SDID`), which facilitates address
 protection fences on a per-supervisor-domain basis; and the `MODE` field, which
-selects the address protection scheme (MTT Mode to be enforced) for physical
-addresses. The MTT is a structure that holds the access permissions for a
+selects the address protection scheme (MPT Mode to be enforced) for physical
+addresses. The MPT is a structure that holds the access permissions for a
 physical address and is looked up per the programmed `MODE`.
 
-Attempts to read or write `mttp` while executing in U or S-mode will raise
+Attempts to read or write `mmpt` while executing in U or S-mode will raise
 an illegal instruction exception.
 
 [caption="Register {counter:rimage}: ", reftext="Register {rimage}"]
-[title="M-mode MTTP register (`mttp`) when `XLEN=32`."]
+[title="MMPT register (`mmpt`) when `XLEN=32`."]
 [id=sdid-32]
 [wavedrom, ,svg]
 ....
@@ -41,7 +41,7 @@ an illegal instruction exception.
 ....
 
 [caption="Register {counter:rimage}: ", reftext="Register {rimage}"]
-[title="M-mode MTTP register (`mttp`) when `XLEN=64`."]
+[title="MMPT register (`mmpt`) when `XLEN=64`."]
 [id=sdid-64]
 [wavedrom, ,svg]
 ....
@@ -53,82 +53,82 @@ an illegal instruction exception.
 ], config:{lanes: 2, hspace:1024}}
 ....
 
-<<mtt-32>> shows the encodings of the `MODE` field when `XLEN=32` and
-<<mtt-64>> shows the encodings of the `MODE` field when `XLEN=64`. When `mttp`
-`MODE=Bare`, supervisor physical addresses have no MTT-based protection across
+<<mpt-32>> shows the encodings of the `MODE` field when `XLEN=32` and
+<<mpt-64>> shows the encodings of the `MODE` field when `XLEN=64`. When `mmpt`
+`MODE=Bare`, supervisor physical addresses have no MPT-based protection across
 supervisor domains beyond the physical memory protection scheme described in
 Section 3.7 of the RISC-V privileged architecture specification cite:[ISA]. In
-this case, the remaining fields (`SDID`, `PPN`) in `mttp` must be set to
+this case, the remaining fields (`SDID`, `PPN`) in `mmpt` must be set to
 zeros. When `XLEN=32`, the other valid setting for
-`MODE` is `Smmtt34` to support read-write-execute
+`MODE` is `Smmpt34` to support read-write-execute
 access permissions for 34-bit system physical addresses.
 
 When `XLEN=64`, other than `BARE`, the other valid settings for `MODE` are
-`Smmtt[46 | 56]` to support read-write-execute permissions for 46-bit and
+`Smmpt[46 | 56]` to support read-write-execute permissions for 46-bit and
 56-bit system physical addresses.
 
 The remaining `MODE` settings when `XLEN=64` are `reserved` for future use and
-may define different interpretations of the other fields in `mttp`.
+may define different interpretations of the other fields in `mmpt`.
 
-.Encoding of `mttp` `MODE` field for `XLEN=32`.
-[width="100%",cols="10%,14%,76%", options="header", id=mtt-32]
+.Encoding of `mmpt` `MODE` field for `XLEN=32`.
+[width="100%",cols="10%,14%,76%", options="header", id=mpt-32]
 |===
 |Value |Name |Description
 |0 |`Bare` | No supervisor domain protection across beyond the physical memory
 protection scheme described in Section 3.7 of the RISC-V privileged architecture
 specification cite:[ISA]
 
-|1 |`Smmtt34` |Page-based supervisor domain protection for up to 34 bit physical
+|1 |`Smmpt34` |Page-based supervisor domain protection for up to 34 bit physical
 addresses with RWX permissions per page
 
 |2-3 |- |`_Reserved_`
 |===
 
-.Encoding of `mttp` `MODE` field for `XLEN=64`.
-[width="100%",cols="10%,14%,76%", options="header", id=mtt-64]
+.Encoding of `mmpt` `MODE` field for `XLEN=64`.
+[width="100%",cols="10%,14%,76%", options="header", id=mpt-64]
 |===
 |Value |Name |Description
 |0 |`Bare` | No supervisor domain protection across beyond the physical memory
 protection scheme described in Section 3.7 of the RISC-V privileged architecture
 specification cite:[ISA]
 
-|1 |`Smmtt46` |Page-based supervisor domain protection for up to 46 bit physical
+|1 |`Smmpt46` |Page-based supervisor domain protection for up to 46 bit physical
 addresses with RWX permissions per page
 
-|2 |`Smmtt56` |Page-based supervisor domain protection for up to 56 bit physical
+|2 |`Smmpt56` |Page-based supervisor domain protection for up to 56 bit physical
 addresses with RWX permissions per page
 
 |3-15 |- |`_Reserved_`
 |===
 
 Implementations are not required to support all defined `MODE` settings when
-`XLEN=64`. A write to `mttp` with an unsupported `MODE` value is not ignored.
-Instead, the fields of `mttp` are `WARL` in the normal way, when so indicated.
+`XLEN=64`. A write to `mmpt` with an unsupported `MODE` value is not ignored.
+Instead, the fields of `mmpt` are `WARL` in the normal way, when so indicated.
 
-The `MTTPPN` refers to an `MTTL3` table or an `MTTL2` table based on physical
-address width (`PAW`). For 56 >= `PAW` > 46, `MTTL3` table must be of size
+The `mmpt.PPN` refers to an `MPTL3` table or an `MPTL2` table based on physical
+address width (`PAW`). For 56 >= `PAW` > 46, `MPTL3` table must be of size
 `2^(PAW-43)` bytes and naturally aligned to that sized byte boundary. For 46
->= `PAW` > 32 the `MTTL2` table must be of size 2^(`PAW`-22) bytes for
-`Smmtt46` and `Smmtt34`, and must be naturally aligned to that sized byte
+>= `PAW` > 32 the `MPTL2` table must be of size 2^(`PAW`-22) bytes for
+`Smmpt46` and `Smmpt34`, and must be naturally aligned to that sized byte
 boundary. In these modes, the lowest two bits of the physical page number
-(`MTTPPN`) in `mttp` always read as zeros.
+(`mmpt.PPN`) in `mmpt` always read as zeros.
 
 The number of `SDID` bits is `UNSPECIFIED` and may be zero. The number of
 implemented `SDID` bits, termed `SDIDLEN`, may be determined by writing one to
-every bit position in the `SDID` field, then reading back the value in `mttp`
+every bit position in the `SDID` field, then reading back the value in `mmpt`
 to see which bit positions in the `SDID` field hold a one. The
 least-significant bits of `SDID` are implemented first: that is, if `SDIDLEN` >
 0, `SDID`[`SDIDLEN`-1:0] is writable. The maximal value of `SDIDLEN`, termed
-`SDIDMAX`, is 6 for `Smmtt[34 | 46 | 56]`.
+`SDIDMAX`, is 6 for `Smmpt[34 | 46 | 56]`.
 
-The `mttp` register is considered active for the purposes of the physical
+The `mmpt` register is considered active for the purposes of the physical
 address protection algorithm unless the effective privilege mode is `M`.
 
-Note that writing `mttp` does not imply any ordering constraints between
+Note that writing `mmpt` does not imply any ordering constraints between
 `S-mode` and `G-stage` page-table updates and subsequent address translations.
-If a supervisor domain's `MTT` structure has been modified, or if a `SDID` is
+If a supervisor domain's `MPT` structure has been modified, or if a `SDID` is
 reused, it may be necessary to execute a `MFENCE.SPA` instruction before or
-after writing `mttp`.
+after writing `mmpt`.
 
 === Machine supervisor domain configuration (`msdcfg`)
 
@@ -190,21 +190,21 @@ domain access-permissions with current execution.
 `MFENCE.SPA` is only valid in M-mode. If operand rs1≠x0, it
 specifies a single physical address, and if rs2≠x0, it specifies a single SDID.
 
-If rs1 corresponds to an `MTT_L1_DIR` mapping, the fence applies to
+If rs1 corresponds to an `MPT_L1_DIR` mapping, the fence applies to
 a 4 KiB page. If rs1 corresponds to a `2M_PAGES` or `4M_PAGES` mapping,
 the fence applies to a 2 MiB or 4 MiB range. If rs1 corresponds to one
 of the 1G_* mappings, the fence applies to a 1 GiB range.
 
 The behavior of `MFENCE.SPA` depends on rs1 and rs2 as follows:
 
-* If rs1=x0 and rs2=x0, the fence orders all reads and writes to the MTT for
+* If rs1=x0 and rs2=x0, the fence orders all reads and writes to the MPT for
 all supervisor domain address spaces.
-* If rs1=x0 and rs2≠x0, the fence orders all reads and writes to the MTT for
+* If rs1=x0 and rs2≠x0, the fence orders all reads and writes to the MPT for
 the supervisor domain address space identified by the SDID in rs2.
-* If rs1≠x0 and rs2=x0, the fence orders all reads and writes made to the MTT
+* If rs1≠x0 and rs2=x0, the fence orders all reads and writes made to the MPT
 that correspond to the physical address in rs1, for all supervisor domain
 address spaces.
-* If rs1≠x0 and rs2≠x0, the fence orders all reads and writes made to the MTT
+* If rs1≠x0 and rs2≠x0, the fence orders all reads and writes made to the MPT
 that correspond to the physical address in rs1, for the supervisor domain
 address space identified by the SDID in rs2.
 
@@ -250,10 +250,10 @@ invalidation of physical memory access-permission caches.
 `MINVAL.SPA` is only ordered against `SFENCE.W.INVAL` and `SFENCE.INVAL.IR`
 instructions. As part of the update to the SD access-permissions, the RDSM must
 ensure that it uses `SFENCE.W.INVAL` to guarantee that any previous stores to
-structures that hold supervisor domain access-permissions (e.g. `MTT`) are made
+structures that hold supervisor domain access-permissions (e.g. `MPT`) are made
 visible before invoking the `MINVAL.SPA`. The RDSM must then use
 `SFENCE.INVAL.IR` to guarantee that all subsequent implicit references to
-supervisor domain access-permission structures (e.g. `MTT`) are ordered to be
+supervisor domain access-permission structures (e.g. `MPT`) are ordered to be
 after the SD access-permissions cache invalidation. When executed in order (but
 not necessarily consecutively) by a single hart, the sequence `SFENCE.W.INVAL`,
 `MINVAL.SPA` and `SFENCE.INVAL.IR` has the same effect as a hypothetical
@@ -280,44 +280,44 @@ VS-level ASID (V=1).
 For S/HS-level ASID, the virtual-address argument to SFENCE.VMA is a host
 virtual address within the current supervisor domain, and the ASID argument is
 a S/HS-level ASID within the current supervisor domain. The current supervisor
-domain is identified by the SDID field of the CSR mttp, and the effective ASID
+domain is identified by the SDID field of the CSR mmpt, and the effective ASID
 can be considered the combination of the SDID and the S/HS-level ASID. The
 SFENCE.VMA orders stores only to this S/HS-level address-translation structures
 with subsequent S/HS-level address translations.
 
 When V=1, the virtual-address argument to SFENCE.VMA is a guest virtual address
 within the current virtual machine, and the ASID argument is a VS-level ASID
 within the current virtual machine. The current virtual machine is identified by
-the SDID field of the CSR mttp and the VMID field of CSR hgatp. The effective
+the SDID field of the CSR mmpt and the VMID field of CSR hgatp. The effective
 ASID within this virtual machine can be considered to be the combination of this
 SDID and VMID along with the VS-level ASID. The SFENCE.VMA instruction orders
 stores only to the VS-level address-translation structures with subsequent
 VS-stage address translations for the same virtual machine, i.e., only when
-mttp.SDID and the hgatp.VMID is the same as when the SFENCE.VMA executed.
+mmpt.SDID and the hgatp.VMID is the same as when the SFENCE.VMA executed.
 
 For HFENCE.GVMA, the guest-physical address argument is within the context of
 the current virtual machine idenfied by the combination of the SDID field of the
-CSR mttp and the VMID field of CSR hgatp. Executing an HFENCE.GVMA guarantees
+CSR mmpt and the VMID field of CSR hgatp. Executing an HFENCE.GVMA guarantees
 that any previous stores already visible to the current hart are ordered before
 all implicit reads by that hart done for G-stage address translation for
-instructions that follow the HFENCE.GVMA, and execute with the same mttp.SDID
+instructions that follow the HFENCE.GVMA, and execute with the same mmpt.SDID
 and hgatp.VMID when HFENCE.GVMA executed.
 
 For HFENCE.VVMA, the guest-virtual address argument is within the context of
 the current virtual machine identified by the combination of the ASID specified
-in the vsatp, the VMID field of CSR hgatp, and the SDID field of CSR mttp.
+in the vsatp, the VMID field of CSR hgatp, and the SDID field of CSR mmpt.
 Executing an HFENCE.VVMA guarantees that any previous stores already visible to
 the current hart are ordered before all implicit reads by that hart done for
 VS-stage address translations for instructions that are subsequent to the
-HFENCE.VMMA and execute when hgatp.VMID and mttp.SDID have the same setting as
+HFENCE.VMMA and execute when hgatp.VMID and mmpt.SDID have the same setting as
 it did when HFENCE.VVMA executed.
 
 === Extension to behavior of `Svinval`
 
 When `Svinval` is implemented with `Smsdid` the behavior of SINVAL.VMA is
-modified to also use the SDID from the CSR mttp in addition to the ASID provided
+modified to also use the SDID from the CSR mmpt in addition to the ASID provided
 in SINVAL.VMA.
 
 When the `Hypervisor` extension is also implemented, the behavior of HINVAL.VVMA
-and HINVAL.GVMA is modified to also use the SDID from the CSR mttp in addition
+and HINVAL.GVMA is modified to also use the SDID from the CSR mmpt in addition
 to the VMID provided in the HINVAL.GVMA or the ASID provided in HINVAL.VVMA.