1. Tech-Privileged
  2. Messages

Re: Caching and sfence'ing (or not) of satp Bare mode "translations"

Bill Huffman
 

Hi Greg,

My sense is that the transitions from SvXX to Bare and from Bare to the same SvXX that was previously in force are special transitions.  One reason seems to me the extreme simplicity of Bare compared with other modes.  It's easier to switch.

If we require sfence.vma after a switch to or from Bare, does that also mean we have to require one after a switch to or from M-mode?  If no, why is it different?  If yes, it will cost more to switch briefly to M-mode than I'd want it to.

      Bill

On 7/20/20 7:08 PM, Greg Favor wrote:

EXTERNAL MAIL

I would like to get people's views on the question of when is an sfence.vma required after changing the satp.mode field (to see what support there is for the following change/clarification in the Privileged spec).

Currently an sfence.vma is required when changing between SvXX modes, but is not required when changing to/from Bare mode.

In both cases there is an implicit wholesale change to the page tables, i.e. the translation of any given address generally has suddenly changed.

For some designs (that cache Bare mode translations in the TLBs for the sake of caching the PMA and PMP info for an address), having software be required to do an sfence.vma can simplify the hardware.

So the question is whether there should be architectural consistency in requiring sfence'ing after changing satp.mode (i.e. all mode changes require an sfence), versus having some mode cases being treated differently (i.e. changes to/from Bare mode not requiring an sfence)?

My (and Ventana's) bias is towards the former - for our sake and for other future high performance CPU designs by others.  But I'm interested to see if others feel similarly or not.

Greg
Join tech-privileged@lists.riscv.org to automatically receive all group messages.