Merge pull request #13 from ved-rivos/0805

Editorial updates

svadu.adoc

@@ -16,12 +16,13 @@ A/D bits. The A and D bits are managed by these extensions as follows:
   PTE updates caused by an explicit or an implicit memory accesses.            +
                                                                                +
   The PTE update must be atomic with respect to other accesses to the PTE, and
-  must atomically check that the PTE is valid and grants sufficient permissions.
-  Updates of the A bit may be performed as a result of speculation, but updates
-  to the D bit must be exact (i.e., not speculative), and observed in program
-  order by the local hart. When two-stage address translation is active, updates
-  of the D bit in G-stage PTEs may be performed as a result of speculative
-  updates of the A bit in VS-stage PTEs.                                       +
+  must atomically check that the PTE is valid and grants sufficient permissions
+  as part of conditionally making the update. Updates of the A bit may be
+  performed as a result of speculation, but updates to the D bit must be exact
+  (i.e., non-speculative), and observed in program order by the local hart. When
+  two-stage address translation is active, updates of the D bit in G-stage PTEs
+  may be performed as a result of speculative updates of the A bit in VS-stage
+  PTEs.                                                                        +
                                                                                +
   The PTE update must appear in the global memory order before the memory access
   that caused the PTE update and before any subsequent explicit memory access to
@@ -37,15 +38,24 @@ A/D bits. The A and D bits are managed by these extensions as follows:
   occur. The hart must not perform the memory access that caused the PTE update
   before the PTE update is globally visible.
 
+[NOTE]
+====
+Simpler implementations that cannot precisely order the PTE update before
+subsequent explicit memory accesses to the associated virtual page by the local
+hart may simply order the PTE update before all subsequent explicit memory
+accesses to any virtual page by the local hart.
+====
+
 Svadu extension requires the page tables to be located in memory with hardware
 page-table write access and _RsrvEventual_ PMA.
 
 The translation of virtual addresses (or guest physical addresses) to physical
 (or guest physical) addresses is accomplished with the same algorithm as
-specified in the Supervisor-Level ISA extension (section 4.3.2) and as modified
-by the hypervisor extension (section 8.5.1), except that step 7 of the
-translation process, instead of causing a page-fault exception due to A and/or D
-bits being 0 when required to be 1, continues as follows:
+specified in the Supervisor-Level ISA extension (section "Virtual Address
+Translation Process") and as modified by the hypervisor extension (section
+"Two-stage Address Translation"), except that step 7 of the translation process,
+instead of causing a page-fault exception due to A and/or D bits being 0 when
+required to be 1, continues as follows:
 
 [start=7]
 . If `pte.a = 0`, or if the original memory access is a store and `pte.d = 0`:
@@ -57,16 +67,17 @@ bits being 0 when required to be 1, continues as follows:
     a store, also set `pte.d` to 1.
 ... If the comparison fails, return to step 2
 
-The Svadu extension adds the `HADE` bit (bit 61) to `menvcfg`. When 
-`menvcfg.HADE` is 1, hardware updating of PTE A/D bits is enabled during
+The Svadu extension adds the `ADUE` bit (bit 61) to `menvcfg`. When
+`menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
 single-stage address translation. When the hypervisor extension is implemented,
-if `menvcfg.HADE` is 1, hardware updating of PTE A/D bits is enabled during
-G-stage address translation.  When `menvcfg.HADE` is zero, the implementation
-behaves as though Svadu were not implemented. If Svadu is not implemented, 
-`menvcfg.HADE` is read-only zero. Furthermore, for implementations with the
-hypervisor extension, `henvcfg.HADE` is read-only zero if `menvcfg.HADE` is zero.
+if `menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
+G-stage address translation.  When `menvcfg.ADUE` is zero, the implementation
+behaves as though Svadu were not implemented. If Svadu is not implemented,
+`menvcfg.ADUE` is read-only zero. Furthermore, for implementations with the
+hypervisor extension, `henvcfg.ADUE` is read-only zero if `menvcfg.ADUE` is zero.
 
 When the hypervisor extension is implemented, the Svadu extension adds the
-`HADE` bit (bit 61) to `henvcfg`. When `henvcfg.HADE` is 1, hardware updating of
-PTE A/D bits is enabled during VS-stage address translation. When `henvcfg.HADE`
-is zero, the implementation behaves as though Svadu were not implemented.
+`ADUE` bit (bit 61) to `henvcfg`. When `henvcfg.ADUE` is 1, hardware updating of
+PTE A/D bits is enabled during VS-stage address translation. When `henvcfg.ADUE`
+is zero, the implementation behaves as though Svadu were not implemented for
+VS-stage address translation.