integrate Svvptc standard extension

1 files changed, 26 insertions, 0 deletions

diff --git a/src/supervisor.adoc b/src/supervisor.adoc
index e9f2855..8575a5e 100644
--- a/src/supervisor.adoc
+++ b/src/supervisor.adoc
@@ -2067,3 +2067,29 @@ See <<sec:menvcfg>> and <<sec:henvcfg>> for the definitions of those fields.
 hardware updating of A/D bits is disabled, the Svade extension, which mandates
 exceptions when A/D bits need be set, instead takes effect.
 The Svade extension is also defined in <<translation>>.
+
+[[sec:svvptc]]
+== "Svvptc" Standard Extension for Eliding Memory-Management Fences on Making 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
+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.
+====