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


Guo Ren
 

On Tue, Aug 2, 2022 at 2:16 PM Greg Favor <gfavor@...> wrote:

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.
Sorry for the typo, It should be:
"The satp and hgatp depend on menvcfg.PBMTE, and the vsatp depends 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.
Good point. I would try; see below.


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).
Svpbmt32 is good, I would put it into



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



and Hypervisor
Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4

Satp doesn't support this mode. Neither does vsatp.
Yes, Sv32. It comes from hgatp, Sv32x4 means 34-bit virtual guest
physical address, right?



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.
Yes, you are right.



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.
Okay. Please have a look at below:

\subsection{``Svpbmt32'' Extension for Page-Based Memory Types}
\label{sec:translation}

The Svpbmt32 extension adds Svpbmt (Chapter~\ref{svpbmt}) support to
Sv32 implementations by reducing the physical address space from
34-bit to 32-bit to hold the highest 2 PBMT bits. The S-mode and
G-stage address translation under this extension are controlled by the
menvcfg.PBMTE. The VS-stage address translation under this extension
is controlled by the henvcfg.PBMTE. The henvcfg.PBMTE depends on
menvcfg.PBMTE.

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt32 and
Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is
Sv32 and menvcfg.PBMTE set, HS-mode virtual addresses and guest
physical addresses are translated to 32-bit physical addresses with
PBMT. When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual
addresses are translated to 32-bit guest physical address with PBMT.
\end{commentary}

Sv32 virtual address:

| 31 22 | 21 12 | 11 0 |
VPN[1] VPN[0] page offset
10 10 12

Sv32 physical address with Svpbmt:

| 31 22 | 21 12 | 11 0 |
PPN[1] PPN[0] page offset
10 10 12

Sv32 page table entry with Svpbmt:

| 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5
| 4 | 3 | 2 | 1 | 0
PBMT PFN[1] PFN[0] reserved for SW D A G U X W R V


Greg

When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical
address with PBMT is translated for V=1.
\end{commentary}
--
Best Regards
Guo Ren

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