Merge pull request #1274 from riscv/svaduriscv-isa-release-b824d33-2024-03-20

Integrate svadu chapter into priv.

2 files changed, 97 insertions, 4 deletions

diff --git a/src/riscv-privileged.adoc b/src/riscv-privileged.adoc
index 3de92b9..7e6665c 100644
--- a/src/riscv-privileged.adoc
+++ b/src/riscv-privileged.adoc
@@ -61,12 +61,12 @@ _Contributors to all versions of the spec in alphabetical order (please contact
 editors to suggest corrections): Krste Asanović, Peter Ashenden, Rimas
 Avižienis, Jacob Bachmeyer, Allen J. Baum, Jonathan Behrens, Paolo Bonzini, Ruslan Bukin,
 Christopher Celio, Chuanhua Chang, David Chisnall, Anthony Coulter, Palmer Dabbelt, Monte
-Dalrymple, Paul Donahue, Greg Favor, Dennis Ferguson,  Marc Gauthier, Andy Glew,
-Gary Guo, Mike Frysinger, John Hauser, David Horner, Olof
-Johansson, David Kruckemyer, Yunsup Lee, Daniel Lustig, Andrew Lutomirski, Prashanth Mundkur,
+Dalrymple, Paul Donahue, Ken Dockser, Aaron Durbin, Greg Favor, Dennis Ferguson,  Marc Gauthier, Andy Glew,
+Gary Guo, Mike Frysinger, John Hauser, David Horner, John Ingalls, Olof
+Johansson, Earl Killian, David Kruckemyer, Yunsup Lee, Daniel Lustig, Andrew Lutomirski, Prashanth Mundkur,
 Jonathan Neuschäfer, Rishiyur
 Nikhil, Stefan O'Rear, Albert Ou, John Ousterhout, David Patterson, Dmitri
-Pavlov, Kade Phillips, Josh Scheid, Colin Schmidt, Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray
+Pavlov, Kade Phillips, Josh Scheid, Colin Schmidt, Ved Shanbhogue, Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray
 VanDeWalker, Megan Wachs, Steve Wallach, Andrew Waterman, Claire Wolf,
 and Reinoud Zandijk.._
 
@@ -95,6 +95,7 @@ include::rnmi.adoc[]
 include::supervisor.adoc[]
 include::sscofpmt.adoc[]
 include::smcntrpmf.adoc[]
+include::svadu.adoc[]
 //hypervisor.tex
 include::hypervisor.adoc[]
 include::sstc.adoc[]
diff --git a/src/svadu.adoc b/src/svadu.adoc
new file mode 100644
index 0000000..f8c4267
--- /dev/null
+++ b/src/svadu.adoc
@@ -0,0 +1,92 @@
+[[svadu]]
+== "Svadu" Hardware Updating of PTE A/D Bits, Version 1.0.0
+
+[[chapter2]]
+=== Hardware Updating of PTE A/D Bits
+
+The Svadu extension adds support and CSR controls for hardware updating of PTE
+A/D bits. The A and D bits are managed by these extensions as follows:
+
+* 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.
+
+[NOTE]
+====
+The PTE updates due to memory accesses ordered-after a FENCE are not themselves
+ordered by the FENCE.
+
+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 "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`:
+.. If a store to `pte` would violate a PMA or PMP check, raise an access-fault
+   exception corresponding to the original access type.
+.. Perform the following steps atomically:
+... Compare `pte` to the value of the PTE at address `a + va.vpn[i] × PTESIZE`.
+... If the values match, set `pte.a` to 1 and, if the original memory access is
+    a store, also set `pte.d` to 1.
+... If the comparison fails, return to step 2
+
+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.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
+`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.
\ No newline at end of file