From 99072002eb0f08e897f5cafe10eb3dd2b2ddc86c Mon Sep 17 00:00:00 2001
From: Ved Shanbhogue <ved@rivosinc.com>
Date: Wed, 3 Jul 2024 06:55:21 -0500
Subject: Update svvptc text following TSC review

---
 src/supervisor.adoc | 39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

(limited to 'src/supervisor.adoc')

diff --git a/src/supervisor.adoc b/src/supervisor.adoc
index daecbc2..8cfe09a 100644
--- a/src/supervisor.adoc
+++ b/src/supervisor.adoc
@@ -2227,29 +2227,32 @@ exceptions when A/D bits need be set, instead takes effect.
 The Svade extension is also defined in <<translation>>.
 
 [[sec:svvptc]]
-== "Svvptc" Extension for Eliding Memory-Management Fences on Making PTEs Valid, Version 1.0
+== "Svvptc" Extension for Obviating Memory-Management Instructions after Marking PTEs Valid, Version 1.0
 
-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 hart's address-translation caches when a memory-resident PTE
+is changed from Invalid to Valid. Synchronizing the hart's 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.
 ====
 
 ////
-- 
cgit v1.1

