Merge pull request #55 from eckhard-delfs-qualcomm/main

Minor typos & improvement suggestions

chapter3.adoc

@@ -11,7 +11,7 @@ associated with the supervisor domain.
 The `mttp` 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 (`MTTPPN`) of the root page of the memory tracking table
+physical page number (`PPN`) of the root page of the memory tracking table
 (`MTT`), 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
@@ -52,7 +52,7 @@ an illegal instruction exception.
 `MODE=Bare`, supervisor physical addresses have no MTT-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`, `MTTPPN`) in `mttp` must be set to
+this case, the remaining fields (`SDID`, `PPN`) in `mttp` must be set to
 zeros, else generate a fault. When `XLEN=32`, the other valid settings for
 `MODE` are `Smmtt34` and `Smmtt34rw`, to support allow/disallow and read-write
 access permissions for 34-bit system physical addresses.
@@ -108,13 +108,13 @@ 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.
 
-The `MTTPPN` refers to an `MTTL3` table or an `MTTL2` table based on physical
+The `PPN` 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
 `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`-23) or 2^(`PAW`-22)
 bytes (depending on the Smmtt `MODE` selected) 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.
+page number (`PPN`) in `mttp` 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
@@ -130,7 +130,7 @@ address protection algorithm unless the effective privilege mode is `M`.
 Note that writing `mttp` 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
-reused, it may be necessary to execute a `FENCE.MTT` instruction before or
+reused, it may be necessary to execute a `MFENCE.SPA` instruction before or
 after writing `mttp`.
 
 === Machine supervisor domain configuration (`msdcfg`)
@@ -183,15 +183,15 @@ respective sections in this specification.
   {bits:  5, name: 'rd (0)'},
   {bits:  3, name: 'func3 (PRIV)'},
   {bits:  5, name: 'rs1 (PADDR)'},
-  {bits:  5, name: 'rs2 (SDID'},
+  {bits:  5, name: 'rs2 (SDID)'},
   {bits:  7, name: 'func7 (MFENCE.SPA)'},
 ], config:{lanes: 1, hspace:1024}}
 ....
 
 The `MFENCE.SPA` fence instruction is used to synchronize updates to supervisor
 domain access-permissions with current execution.
-`MFENCE.SPA` is only valid in M-mode. If operand rs1 is not equal to x0, it
-specifies a single physical address, and if rs2 is not equal to 0, it specifies
+`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. 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 supervisor domain access-permission structures for
@@ -226,7 +226,7 @@ invalidation of physical memory access-permission caches.
   {bits:  5, name: 'rd (0)'},
   {bits:  3, name: 'func3 (PRIV)'},
   {bits:  5, name: 'rs1 (PADDR)'},
-  {bits:  5, name: 'rs2 (SDID'},
+  {bits:  5, name: 'rs2 (SDID)'},
   {bits:  7, name: 'func7 (MINVAL.SPA)'},
 ], config:{lanes: 1, hspace:1024}}
 ....

chapter4.adoc

@@ -4,7 +4,7 @@
 
 === Smmtt[34, 46, 56]rw
 
-The `MTTPPN` rooted structure for the MTT is shown below. The structure
+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 `MTTL3` table is not applicable. In this mode of the
 Smmtt[34, 46, 56]rw, each page is associated with a read and a write access
@@ -125,10 +125,10 @@ domain
 
 === Smmtt[34, 46, 56]
 
-The MTTPPN rooted structure for the MTT is shown below. The structure
+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
-SmmttX, 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}"]

chapter6.adoc

@@ -47,7 +47,7 @@ IO devices can initiate DMA transactions utilizing IO Virtual Addresses (IOVA).
 Notably, an IOVA could be in the form of a Virtual Address (VA), Guest Virtual
 Address (GVA), or Guest Physical Address (GPA). The configuration and
 interfacing of the I/O MTT Checker with respect to the IO Bridge is graphically
-represented in the diagram <<fig:IOMTTCHK>>.
+represented in <<io-mtt-checker>>.
 
 [caption="Figure {counter:image}: ", reftext="Figure {image}"]
 [title= "I/O MTT checker placement", id=io-mtt-checker]

glossary.adoc

@@ -47,8 +47,8 @@ by virtualizing hart, guest physical memory and input/output (IO) resources.
 
 | MTT | Memory Tracking Table (MTT).
 
-| Relying party | An entity that An entity that uses the attestation process
-to assesses the trustworthiness of an attester.
+| Relying party | An entity that uses the attestation process
+to assess the trustworthiness of an attester.
 
 | Supervisor Domain (SD) | A RISC-V privileged architecture extension defined in
 this specification, to support isolation across more than one supervisor
@@ -67,7 +67,7 @@ execution against a defined adversary model. In a system with separate
 processing elements within a package on a socket, the TCB boundary is the
 package. In a multi-socket system the Hardware TCB extends across the
 socket-to-socket interface, and is managed as one system TCB. The software TCB
-may also extends across multiple sockets.
+may also extend across multiple sockets.
 
 | TEE | Trusted execution environment (TEE) is a set of hardware and software
 mechanisms that allow creating attestable and isolated execution environment.