1. Tech-Privileged
  2. Messages

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Greg Favor
 

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.
vsatp depends on henvcfg.PBMTE, and henvcfg.PBMTE depends on
menvcfg.PBMTE. Here is the rewritten sentence:

The Sv32 Svpbmt extension adds Svpbmt (Chapter~\ref{svpbmt}) support
to Sv32 implementations by reducing the physical address space from
34-bit to 32-bit and leaving the highest 2 bits of the leaf PTE as
PBMT properties for two-level translation. The satp and hgatp depend
on henvcfg.PBMTE, and the vsatp depends on henvcfg.PBMTE.

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).
 

How about:

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt

Note that you can't use the same name 'Svpmt' for this new extension.  Every extension must have a distinct name of its own.
 
and Hypervisor
Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4

Satp doesn't support this mode.  Neither does vsatp.
 
and
menvcfg.PBMTE set, 32-bit physical address with PBMT is translated

Note that physical addresses are not "translated"; they are the result of a translation.  Virtual addresses are "translated" into physical addresses.
 
for V=0.

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.
 
Greg

When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical
address with PBMT is translated for V=1.
\end{commentary}
 
Join tech-privileged@lists.riscv.org to automatically receive all group messages.