Merge pull request #16 from ved-rivos/tsc_update

Updates from TSC review

svvptc.adoc

@@ -1,5 +1,5 @@
 [[header]]
-:description: Eliding Memory-Management Fences on Making PTEs Valid (Svvptc)
+:description: Obviating Memory-Management Instructions after Marking PTEs Valid (Svvptc)
 :company: RISC-V.org
 :revdate: 03/2024
 :revnumber: 1.0
@@ -36,7 +36,7 @@ endif::[]
 :footnote:
 :xrefstyle: short
 
-= Eliding Memory-Management Fences on Making PTEs Valid (Svvptc)
+= Obviating Memory-Management Instructions after Marking PTEs Valid (Svvptc)
 
 // Preamble
 [WARNING]
@@ -60,30 +60,33 @@ Copyright 2024 by RISC-V International.
 [preface]
 === Contributors
 This RISC-V specification has been contributed to directly or indirectly by:
-Alexandre Ghiti, Andrea Parri, Andrew Waterman, Greg Favor, Ken Dockser,
-Krste Asanovic, Ved Shanbhogue
+Alexandre Ghiti, Andrea Parri, Andrew Waterman, David Weaver, Greg Favor,
+Guy Lemieux, Ken Dockser, Krste Asanovic, Ved Shanbhogue
 
-== Eliding Memory-Management Fences on Making PTEs Valid (Svvptc)
+== Obviating Memory-Management Instructions after Marking PTEs Valid (Svvptc)
 
-When the Svvptc extension is implemented, explicit stores that update the Valid
-bit of leaf and/or non-leaf PTEs from 0 to 1 and are visible to a hart will
-eventually become visible within a bounded timeframe to subsequent implicit
+When the Svvptc extension is implemented, explicit stores by a hart that update
+the Valid bit of leaf and/or non-leaf PTEs from 0 to 1 and are visible to a hart
+will eventually become visible within a bounded timeframe to subsequent implicit
 accesses by that hart to such PTEs.
 
 [NOTE]
 ====
-Typically, PTEs are marked as Valid by the operating system following a
-page-fault exception or during system calls for memory mapping. In such cases,
-the trap handler commonly employs an `SRET` instruction to return from the trap.
-When Svvptc is implemented, the stores it executes to change the Valid bit
-of the PTEs from 0 to 1 then become visible to implicit references to those PTEs
-within a bounded timeframe. This visibility pertains to the instructions like
-the one causing the page-fault or those accessing new memory regions. A
-memory-management fence can be used to force immediate visibility of these PTE
-updates to all implicit references associated with instructions following the
-memory-management fence. However, when Svvptc is implemented, visibility (in a
-bounded amount of time) is guaranteed and use of a memory-management fence is
-not required in these scenarios. While this approach might lead to an occasional
-gratuitous page-fault, the performance benefit of omitting the memory-management
-fence instructions outweighs the occasional cost of a gratuitous page-fault.
+Svvptc relieves an operating system from executing certain memory-management
+instructions, such as `SFENCE.VMA` or `SINVAL.VMA`, which would normally be used
+to synchronize the address-translation caches when a memory-resident PTE is
+changed from Invalid to Valid. Synchronizing the address-translation caches with
+other forms of updates to a memory-resident PTE, including when a PTE is changed
+from Valid to Invalid, requires the use of suitable memory-management
+instructions. Svvptc guarantees that a change to a PTE from Invalid to Valid is
+made visible within a bounded time, thereby making the execution of these
+memory-management instructions redundant. The performance benefit of eliding
+these instructions outweighs the cost of an occasional gratuitous additional
+page fault that may occur.
+
+Depending on the microarchitecture, some possible ways to facilitate
+implementation of Svvptc include: not having any address-translation caches, not
+storing Invalid PTEs in the address-translation caches, automatically evicting
+Invalid PTEs using a bounded timer, or making address-translation caches
+coherent with store instructions that modify PTEs.
 ====