From ec4492fe51a5186c4b0a8b83b0dac622beb341c3 Mon Sep 17 00:00:00 2001 From: Andrew Waterman Date: Fri, 21 Jun 2019 16:36:05 -0700 Subject: Clarify SBE/SFENCE interaction --- src/machine.tex | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'src') diff --git a/src/machine.tex b/src/machine.tex index 6c79e4c..ca3b543 100644 --- a/src/machine.tex +++ b/src/machine.tex @@ -753,9 +753,20 @@ accesses to such pages made from S-mode with {\tt sstatus}.SUM=1. For {\em implicit} accesses to supervisor-level memory management data structures, such as page tables, endianness is always controlled by SBE. Since changing SBE alters the implementation's interpretation of these data -structures, M-mode software must follow a change to SBE by executing an +structures, if any such data structures remain in use across a change to SBE, +M-mode software must follow such a change to SBE by executing an SFENCE.VMA instruction with {\em rs1}={\tt x0} and {\em rs2}={\tt x0}. +\begin{commentary} +Only in contrived scenarios will a given memory-management data structure be +interpreted as both little-endian and big-endian. +In practice, SBE will only be changed at runtime on world switches, in which +case neither the old nor new memory-management data structure will be +reinterpreted in a different endianness. +In this case, no additional SFENCE.VMA is necessary, beyond what would +ordinarily be required for a world switch. +\end{commentary} + If S-mode is supported, an implementation may hardwire SBE so that SBE=MBE. If U-mode is supported, an implementation may hardwire UBE so that -- cgit v1.1