Re: xTVAL Compliance restriction proposal


Andrew Waterman
 

The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit.  The extra 1 bit allows for zero-extension of PAs.


On Tue, Jun 30, 2020 at 6:19 PM Allen Baum <allen.baum@...> wrote:
You said:
  Sign extend if translated
 Zero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that)

Then you said that the extension would be from the highest address bit-  but if VA>PA, isn’t that effectively zero extending the PA even in bare mode? That seems to contradict the first statement.

As usual, I’m probably interpreting something  which might be interpreted more than one way in exactly the wrong way- that is my superpower.  What am I getting wrong? Compliance wants to know!


-Allen

On Jun 30, 2020, at 12:45 PM, Greg Favor <gfavor@...> wrote:

Coming back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:

On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode.  In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.

Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.

Greg

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