aboutsummaryrefslogtreecommitdiff
path: root/src/supervisor.adoc
diff options
context:
space:
mode:
authorVed Shanbhogue <ved@rivosinc.com>2024-07-03 06:55:21 -0500
committerVed Shanbhogue <ved@rivosinc.com>2024-07-03 06:55:21 -0500
commit99072002eb0f08e897f5cafe10eb3dd2b2ddc86c (patch)
treeacc0ba0953941c8ba4f8c3b5bf654a0ce3fac19a /src/supervisor.adoc
parent077e6277dc26412665f8e7f3b1bb4e8615cb4e21 (diff)
downloadriscv-isa-manual-99072002eb0f08e897f5cafe10eb3dd2b2ddc86c.zip
riscv-isa-manual-99072002eb0f08e897f5cafe10eb3dd2b2ddc86c.tar.gz
riscv-isa-manual-99072002eb0f08e897f5cafe10eb3dd2b2ddc86c.tar.bz2
Update svvptc text following TSC review
Diffstat (limited to 'src/supervisor.adoc')
-rw-r--r--src/supervisor.adoc39
1 files changed, 21 insertions, 18 deletions
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.
====
////