Clarifications to the Addressing and Memory Protection section (#1142)

* updating with all clarifications in Svadu to section 5.3.1

* remove repeated sentence

* simplify sentence

src/supervisor.adoc

@@ -1235,30 +1235,60 @@ Two schemes to manage the A and D bits are permitted:
 
 * When a virtual page is accessed and the A bit is clear, or is written
 and the D bit is clear, a page-fault exception is raised.
-* When a virtual page is accessed and the A bit is clear, or is written
-and the D bit is clear, the implementation sets the corresponding bit(s)
-in the PTE. 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.
-Furthermore, the PTE update must appear in the global memory order no
-later than the explicit memory access, or any subsequent explicit memory
-access to that virtual page by the local hart. The ordering on loads and
-stores provided by FENCE instructions and the acquire/release bits on
-atomic instructions also orders the PTE updates associated with those
-loads and stores as observed by remote harts.
-+
-The PTE update is not required to be atomic with respect to the explicit
-memory access that caused the update, and the sequence is interruptible.
-However, the hart must not perform the explicit memory access before the
-PTE update is globally visible.
+* When a virtual page is accessed and the A bit is clear, the PTE is
+  updated to set the A bit.  When the virtual page is written and the D
+  bit is clear, the PTE is updated to set the D bit. When G-stage address
+  translation is in use and is not Bare, the G-stage virtual pages may be
+  accessed or written by implicit accesses to VS-level memory management
+  data structures, such as page tables.                                 +
+                                                                        +
+  When two-stage address translation is in use, an explicit access may
+  cause both VS-stage and G-stage PTEs to be updated. The following rules
+  apply to all 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 perform all tablewalk checks for that leaf
+  PTE as part of, and before, conditionally updating the PTE value.
+  Updates of the A bit may be performed as a result of speculation, even
+  if the associated memory access ultimately is not performed
+  architecturally. However, updates to the D bit, resulting from an
+  explicit store, 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 that virtual page by the local hart. The
+  ordering on loads and stores provided by FENCE instructions and the
+  acquire/release bits on atomic instructions also orders the PTE updates
+  associated with those loads and stores as observed by remote harts.   +
+                                                                        +
+  The PTE update is not required to be atomic with respect to the memory
+  access that caused the update and a trap may occur between the PTE
+  update and the memory access that caused the PTE update. If a trap
+  occurs then the A and/or D bit may be updated but the memory access
+  that caused the PTE update might not occur. The hart must not perform
+  the memory access that caused the PTE update before the PTE update is
+  globally visible.                                                     +
+                                                                        +
+  The page tables must be located in memory with hardware page-table
+  write access and _RsrvEventual_ PMA.
 
 All harts in a system must employ the same PTE-update scheme as each
 other.
 
 [NOTE]
 ====
+The PTE updates due to memory accesses ordered-after a FENCE are not
+themselves ordered by the FENCE.
+
+Simpler implementations may order the Page Table Entry (PTE) update
+to precede all subsequent explicit memory accesses, as opposed to
+ensuring that the PTE update is precisely sequenced before subsequent
+explicit memory accesses to the associated virtual page.
+
 Prior versions of this specification required PTE A bit updates to be
 exact, but allowing the A bit to be updated as a result of speculation
 simplifies the implementation of address translation prefetchers. System