Re: Caching and sfence'ing (or not) of satp Bare mode "translations"
On Mon, Jul 20, 2020 at 8:14 PM Bill Huffman <huffman@...> wrote:
Switches to/from Bare mode should be rare. Typically one will switch from Bare mode to a translated mode as part of booting up an OS (e.g. Linux), and then will remain in that mode (until, say, the system crashes and must reboot). Further, all such switches are performed under full software control.
Switching to/from M-mode on the other hand is frequent and often hardware initiated. Also, any sfence.vma on M-mode exit would have to be after the exit (in potentially arbitrary code that happens to be at the return address).
Hence sfence'ing M-mode entry/exit is impractical as well as something that needs to be performant. Whereas Bare mode entry/exit is rare and software-managed.
If a high-performance design caches "translations" in all modes of operation (including M-mode) in the TLBs, then M-mode translations must be distinguished from S/HS/U mode translations, which must be distinguished from VS/VU mode translations. That is a small set of three translation regimes (to use an ARMv8 term) for hardware to support and handle properly.
If one has to also distinguish Bare and non-Bare modes within the S/HS/U translation regime, that effectively becomes two separate translation regimes. Similarly, with the H-extension and two-stage translations inside VM's, the VS/VU regime needs to become four regimes (the four combinations of Bare and non-Bare stage 1 and stage 2 modes). Consequently TLB entries and surrounding logic now need to distinguish between and properly handle seven translation regimes. All to handle rare cases.
That, like most things, is doable, but isn't the whole point of a RISC architecture to reduce hardware cost and complexity and shift that to software where the software burden is small and the performance cost is minimal?
P.S. One could imagine instead doing data-dependent implicit sfence.vma operation on CSR writes to the *atp registers, but besides being data-dependent (which RISC-V avoids when it comes to having data-dependent exceptions) that is a rather CISC'y thing to do. Which goes back to my preceding point.