Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"
On Mon, Aug 1, 2022 at 7:45 PM Guo Ren <guoren@...> wrote:
> For vsatp both menvcfg AND henvcfg matter - as is the case in general for features in VS/VU modes that are controlled by the *envcfg CSRs.
The preceding, as worded, could be simplified down to "The satp, hgatp, and vsatp CSRs all depend on henvcfg.PBMTE."
But the above sentence is not correct in that satp does not depend on henvcfg.PBMTE. And hgatp also does not depend on henvcfg.PBMTE.
It would be better to not try and redundantly repeat what is already specified in the Priv arch spec (and possibly get it wrong). Instead, using the same terminology as used in the description of the PBMTE bits, say that S-mode, G-stage, and VS-stage address translation under this extension are controlled by the menvcfg.PBMTE and henvcfg.PBMTE bits in the same manner as for the SvPbmt extension.
Or even better, just expand the references to Svpbmt in the two PBMTE description to refer to both Svpbmt and Svpbmt32 (as a possible name for this extension).
Note that you can't use the same name 'Svpmt' for this new extension. Every extension must have a distinct name of its own.
Satp doesn't support this mode. Neither does vsatp.
Note that physical addresses are not "translated"; they are the result of a translation. Virtual addresses are "translated" into physical addresses.
Note that satp is only used when V=0; vsatp is used when V=1. So the "V=0" qualifier for satp is not only unnecessary but also undesirable in suggesting that the qualifier has some significance of its own.
When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical