tech-privileged@lists.riscv.org | Fast-track extension proposal V2 for "Sv32 Svpbmt"

Home Messages Hashtags Subgroups

Date Date 1 - 8 of 8

Fast-track extension proposal V2 for "Sv32 Svpbmt"

Guo Ren

On Wed, Aug 3, 2022 at 9:10 PM Guo Ren <guoren@...> wrote:

On Wed, Aug 3, 2022 at 12:46 AM Greg Favor <gfavor@...> wrote:

On Tue, Aug 2, 2022 at 4:48 AM Guo Ren <guoren@...> wrote:

and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4Satp doesn't support this mode.  Neither does vsatp.Yes, Sv32. It comes from hgatp, Sv32x4 means 34-bit virtual guest
physical address, right?
Yes.


The Svpbmt32 extension adds Svpbmt
The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added).Okay.



(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
Maybe say "... to allow use of the two highest bits instead as PBMT bits."Okay.



. 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.
Maybe say "... controlled by henvcfg.PBMTE and indirectly also menvcfg.PBMTE."Okay.



\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.
It would be better to describe this in the same way as the existing PBMTE description, i.e. "When menvcfg.PBMTE=1, Svpbmt32 is available for S-mode and G-stage address translation."

Ultimately these statements will need to be incorporated into the two existing PBMTE descriptions (for menvcfg and henvcfg), but in the meantime one should use the same wording as the existing descriptions.Okay, I would try; see below.



When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual
addresses are translated to 32-bit guest physical address with PBMT.
\end{commentary}
Same comment as above.

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:
I assume the preceding should be 'Svpbmt32'.Okay



| 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
What does 'PFN' stand for?  But more importantly why change names from PPN to PFN (versus maintaining the same naming as in the existing spec)?  Especially since PFN[0] is the same as PPN[0], and PFN[1] is just a smaller version of PPN[1].Okay, I will fix it.


\subsection{Svpbmt32}
.\label{sec:translation}

Svpbmt32 support is being added to allow the two highest bits of PTE
used as PBMT for Sv32. 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
henvcfg.PBMTE and menvcfg.PBMTE indirectly.Update above with Allen help, to make the description flow better:

Svpbmt32 support is being added to allow the two highest bits of a PTE
to be used as PBMT instead of PA[33:32] for Sv32. 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 henvcfg.PBMTE and indirectly by menvcfg.PBMTE.


\begin{commentary}
For example, consider an RV32 system supporting Svpbmt32 and
Hypervisor Extension (Chapter~\ref{hypervisor}). When menvcfg.PBMTE=1,
Svpbmt32 is available for S-mode and G-stage address translation. When
henvcfg.PBMTE=1, Svpbmt32 is available for VS-mode address
translation.
\end{commentary}

Sv32 virtual address:
| 31    22 | 21     12 | 11          0 |
  VPN[1]    VPN[0]   page offset
    10       10         12

Sv32 physical address with Svpbmt32:
| 31    22 | 21     12 | 11           0 |
 PPN[1]     PPN[0]    page offset
    10             10         12

Sv32 page table entry with Svpbmt32:
| 31 30 | 29     20 | 19     10 | 9                      8 | 7 | 6 | 5
| 4 | 3 | 2 | 1 | 0
  PBMT   PPN[1]     PPN[0]   reserved for SW   D   A  G  U   X  W  R  V


Greg

--
Best Regards
 Guo Ren

-- 
Best Regards
 Guo Ren

Guo Ren

#1085

On Wed, Aug 3, 2022 at 12:46 AM Greg Favor <gfavor@...> wrote:

On Tue, Aug 2, 2022 at 4:48 AM Guo Ren <guoren@...> wrote:

and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4Satp doesn't support this mode.  Neither does vsatp.Yes, Sv32. It comes from hgatp, Sv32x4 means 34-bit virtual guest
physical address, right?
Yes.


The Svpbmt32 extension adds Svpbmt
The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added).Okay.



(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
Maybe say "... to allow use of the two highest bits instead as PBMT bits."Okay.



. 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.
Maybe say "... controlled by henvcfg.PBMTE and indirectly also menvcfg.PBMTE."Okay.



\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.
It would be better to describe this in the same way as the existing PBMTE description, i.e. "When menvcfg.PBMTE=1, Svpbmt32 is available for S-mode and G-stage address translation."

Ultimately these statements will need to be incorporated into the two existing PBMTE descriptions (for menvcfg and henvcfg), but in the meantime one should use the same wording as the existing descriptions.Okay, I would try; see below.



When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual
addresses are translated to 32-bit guest physical address with PBMT.
\end{commentary}
Same comment as above.

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:
I assume the preceding should be 'Svpbmt32'.Okay



| 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
What does 'PFN' stand for?  But more importantly why change names from PPN to PFN (versus maintaining the same naming as in the existing spec)?  Especially since PFN[0] is the same as PPN[0], and PFN[1] is just a smaller version of PPN[1].Okay, I will fix it.


\subsection{Svpbmt32}
.\label{sec:translation}

Svpbmt32 support is being added to allow the two highest bits of PTE
used as PBMT for Sv32. 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
henvcfg.PBMTE and menvcfg.PBMTE indirectly.

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt32 and
Hypervisor Extension (Chapter~\ref{hypervisor}). When menvcfg.PBMTE=1,
Svpbmt32 is available for S-mode and G-stage address translation. When
henvcfg.PBMTE=1, Svpbmt32 is available for VS-mode address
translation.
\end{commentary}

Sv32 virtual address:
| 31    22 | 21     12 | 11          0 |
  VPN[1]    VPN[0]   page offset
    10       10         12

Sv32 physical address with Svpbmt32:
| 31    22 | 21     12 | 11           0 |
 PPN[1]     PPN[0]    page offset
    10             10         12

Sv32 page table entry with Svpbmt32:
| 31 30 | 29     20 | 19     10 | 9                      8 | 7 | 6 | 5
| 4 | 3 | 2 | 1 | 0
  PBMT   PPN[1]     PPN[0]   reserved for SW   D   A  G  U   X  W  R  V


Greg

--
Best Regards
 Guo Ren

Greg Favor

#1084

On Tue, Aug 2, 2022 at 4:48 AM Guo Ren <guoren@...> wrote:

>> 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?

Yes.

The Svpbmt32 extension adds Svpbmt

The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added).

(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

Maybe say "... to allow use of the two highest bits instead as 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.

Maybe say "... controlled by henvcfg.PBMTE and indirectly also 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.

It would be better to describe this in the same way as the existing PBMTE description, i.e. "When menvcfg.PBMTE=1, Svpbmt32 is available for S-mode and G-stage address translation."

Ultimately these statements will need to be incorporated into the two existing PBMTE descriptions (for menvcfg and henvcfg), but in the meantime one should use the same wording as the existing descriptions.

When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual
addresses are translated to 32-bit guest physical address with PBMT.
\end{commentary}

Same comment as above.

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:

I assume the preceding should be 'Svpbmt32'.

| 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

What does 'PFN' stand for? But more importantly why change names from PPN to PFN (versus maintaining the same naming as in the existing spec)? Especially since PFN[0] is the same as PPN[0], and PFN[1] is just a smaller version of PPN[1].

Greg

Guo Ren

#1083

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

Greg Favor

#1082

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}

Guo Ren

#1081

Hi Greg,

Thx for the review, here is my reply.

On Tue, Aug 2, 2022 at 1:40 AM Greg Favor <gfavor@...> wrote:

Below are my comments ...

On Mon, Aug 1, 2022 at 3:34 AM Guo Ren <guoren@...> wrote:

First note that a ratified extension will probably appear in the Priv spec as a separate chapter (as was done with the three Sv* extensions ratified last year), or it might be included as part of the Svpbmt chapter as a separate section.  Tbd.Agree, I would put it in the Svpbmt chapter as a separate section.


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,
when {\tt menvcfg}.PBMTE (for V=0) or
The OR is incorrect.  For satp only menvcfg matters.My meaning here is satp with V=0 or V=1, but I agree using vsatp is clearer.

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. When
menvcfg.PBMTE not set, henvcfg.PBMTE must be zero.



{\tt henvcfg}.PBMTE (for V=1)
... is ...

set. Then
the 20-bit VPN is translated into a 20-bit physical page number (PPN),
This is only true for 4 KiB pages.  What about larger page sizes?  This probably needs to be expressed in a manner that is page size agnostic.I think the sentence could be removed. Look at the below commentary part.



and

the highest 2 bits
... of the leaf PTE ...Yes, I've done.


are PBMT properties.

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension
(Chapter~\ref{hypervisor}). When {\tt vsatp}.MODE is Sv32x4 and
the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT
attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is
Sv32x4
Satp does not support this translation mode.  And satp is not dependent on menvcfg.  (Conversely vsatp is dependent on both memvcfg AND henvcfg.)

More generally this whole paragraph seems to either have a number of errors or is poorly worded.  Also the intro - that says to consider a system supporting the H extension -  would seem to focus in on vstap, but then the paragraph starts talking about satp.  It probably would be good to have separate paragraphs for the satp functionality and the vsatp functionality (especially since this extension is not limited to use only in virtualized environments).How about:

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt and Hypervisor
Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4 and
menvcfg.PBMTE set, 32-bit physical address with PBMT is translated for
V=0. When vsatp.mode is Sv32x4 and henvcfg.PBMTE set, 32-bit physical
address with PBMT is translated for V=1.
\end{commentary}



and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced
with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit
({\tt henvcfg}.PBMTE = 0) guest physical address.
\end{commentary}

Sv32 virtual address with Svpbmt:

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


Sv32 physical address with Svpbmt:
Isn't this for without 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     10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  MT[2]      PFN      reserved for SW   D   A   G   U   X   W   R   VBy merging PPN[1] and PPN[0], this seems to only apply to 4K leaf PTEs?  Is that intended or why the merging?I separate them in latex diff; the style is from the Linux comment.

| 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


Why the '[2]' suffix to 'MT'?  PFN doesn't have such a suffix.  Conversely the above PPN's have a suffix to distinguish between the two PPN fields.This means 2 bits for PBMT, it's from the Linux comment. I agree with
using the spec style here.


Greg

-- 
Best Regards
 Guo Ren

Greg Favor

#1080

Below are my comments ...

Show quoted text

On Mon, Aug 1, 2022 at 3:34 AM Guo Ren <guoren@...> wrote:

First note that a ratified extension will probably appear in the Priv spec as a separate chapter (as was done with the three Sv* extensions ratified last year), or it might be included as part of the Svpbmt chapter as a separate section. Tbd.

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,

when {\tt menvcfg}.PBMTE (for V=0) or

The OR is incorrect. For satp only menvcfg matters. 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.

{\tt henvcfg}.PBMTE (for V=1)

... is ...

set. Then

the 20-bit VPN is translated into a 20-bit physical page number (PPN),

This is only true for 4 KiB pages. What about larger page sizes? This probably needs to be expressed in a manner that is page size agnostic.

and

the highest 2 bits

... of the leaf PTE ...

are PBMT properties.

\begin{commentary}

For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension

(Chapter~\ref{hypervisor}). When the value of {\tt vsatp}.MODE is Sv32x4 and

the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT

attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is

Sv32x4

Satp does not support this translation mode. And satp is not dependent on menvcfg. (Conversely vsatp is dependent on both memvcfg AND henvcfg.)

More generally this whole paragraph seems to either have a number of errors or is poorly worded. Also the intro - that says to consider a system supporting the H extension - would seem to focus in on vstap, but then the paragraph starts talking about satp. It probably would be good to have separate paragraphs for the satp functionality and the vsatp functionality (especially since this extension is not limited to use only in virtualized environments).

and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced

with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit

({\tt henvcfg}.PBMTE = 0) guest physical address.

\end{commentary}

Sv32 virtual address with Svpbmt:
| 31  22 | 21  12 | 11        0 |
  VPN[1]   VPN[0]   page offset
    10       10         12
Sv32 physical address with Svpbmt:

Isn't this for without 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     10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  MT[2]      PFN      reserved for SW   D   A   G   U   X   W   R   V

By merging PPN[1] and PPN[0], this seems to only apply to 4K leaf PTEs? Is that intended or why the merging?

Why the '[2]' suffix to 'MT'? PFN doesn't have such a suffix. Conversely the above PPN's have a suffix to distinguish between the two PPN fields.

Greg

Guo Ren

#1079

Hi,

Here is the second version of the proposal.

The current Privileged specification only defines Svpbmt for RV64 with the 62-61 bits in PTE, and there are no spare highest bits in rv32 for 34-bit physical addressing. But "the lack of rv32 in svpbmt was a very odd choice [1]" mentioned by Christoph Hellwig (Linux DMA MAPPING HELPERS Maintainer), that's very true in practice requirements, and it also blocks the development of rv32-Linux cost-down chip production.

Rv32-Linux currently only supports 1GB of DRAM for maximum, and there is no plan for high-memory. So, there seems to be no obstacle to shrinking the physical address space of the rv32 from 16GB to 4GB. Then we have 31-30 bits to hold Svpbmt.

The draft spec below provides all the details. Note that this extension very specifically strives to maintain maximal consistency with many little details in the existing Privileged architecture.

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.

Thanks,

Guo Ren

========================================================================

======================= Supervisor Extension Additions ========================

\subsection{Sv32 Svpbmt}

\label{sec:translation}

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,

when {\tt menvcfg}.PBMTE (for V=0) or {\tt henvcfg}.PBMTE (for V=1) set. Then

the 20-bit VPN is translated into a 20-bit physical page number (PPN), and

the highest 2 bits are PBMT properties.

\begin{commentary}

For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension

(Chapter~\ref{hypervisor}). When the value of {\tt vsatp}.MODE is Sv32x4 and

the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT

attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is

Sv32x4 and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced

with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit

({\tt henvcfg}.PBMTE = 0) guest physical address.

\end{commentary}

Sv32 virtual address with Svpbmt:

| 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     10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  MT[2]      PFN      reserved for SW   D   A   G   U   X   W   R   V

========================================================================

================================ Latex diff ===============================

diff --git a/src/supervisor.tex b/src/supervisor.tex
index 30e52264328b..eac8e8b7210a 100644
--- a/src/supervisor.tex
+++ b/src/supervisor.tex
@@ -1657,6 +1657,106 @@ For implementations with both page-based virtual memory and the ``A'' standard
 extension, the LR/SC reservation set must lie completely within a single
 base page (i.e., a naturally aligned \wunits{4}{KiB} region).

+\subsection{Sv32 Svpbmt}
+\label{sec:translation}
+
+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,
+when {\tt menvcfg}.PBMTE (for V=0) or {\tt henvcfg}.PBMTE (for V=1) set. Then
+the 20-bit VPN is translated into a 20-bit physical page number (PPN), and
+the highest 2 bits are PBMT properties.
+
+\begin{commentary}
+For example, consider an RV32 system supporting Svpbmt and Hypervisor Extension
+(Chapter~\ref{hypervisor}). When the value of {\tt vsatp}.MODE is Sv32x4 and
+the {\tt henvcfg}.PBMTE set, a 32-bit physical address is produced with PBMT
+attribute when in VS-mode and VU-mode. When the value of {\tt satp}.MODE is
+Sv32x4 and the {\tt menvcfg}.PBMTE set, a 32-bit physical address is produced
+with PBMT attribute from 32-bit ({\tt henvcfg}.PBMTE = 1) or 34-bit
+({\tt henvcfg}.PBMTE = 0) guest physical address.
+\end{commentary}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}O@{}O@{}E}
+\instbitrange{31}{22} &
+\instbitrange{21}{12} &
+\instbitrange{11}{0} \\
+\hline
+\multicolumn{1}{|c|}{VPN[1]} &
+\multicolumn{1}{c|}{VPN[0]} &
+\multicolumn{1}{c|}{page offset} \\
+\hline
+10 & 10 & 12 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 virtual address with Svpbmt.}
+\label{sv32va}
+\end{figure*}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{@{}E@{}O@{}E}
+\instbitrange{31}{22} &
+\instbitrange{21}{12} &
+\instbitrange{11}{0} \\
+\hline
+\multicolumn{1}{|c|}{PPN[1]} &
+\multicolumn{1}{c|}{PPN[0]} &
+\multicolumn{1}{c|}{page offset} \\
+\hline
+10 & 10 & 12 \\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 physical address with Svpbmt.}
+\label{rv32va}
+\end{figure*}
+
+\begin{figure*}[h!]
+{\footnotesize
+\begin{center}
+\begin{tabular}{F@{}O@{}O@{}Fcccccccc}
+\instbitrange{31}{30} &
+\instbitrange{29}{20} &
+\instbitrange{19}{10} &
+\instbitrange{9}{8} &
+\instbit{7} &
+\instbit{6} &
+\instbit{5} &
+\instbit{4} &
+\instbit{3} &
+\instbit{2} &
+\instbit{1} &
+\instbit{0} \\
+\hline
+\multicolumn{1}{|c|}{PBMT} &
+\multicolumn{1}{|c|}{PPN[1]} &
+\multicolumn{1}{c|}{PPN[0]} &
+\multicolumn{1}{c|}{RSW} &
+\multicolumn{1}{c|}{D} &
+\multicolumn{1}{c|}{A} &
+\multicolumn{1}{c|}{G} &
+\multicolumn{1}{c|}{U} &
+\multicolumn{1}{c|}{X} &
+\multicolumn{1}{c|}{W} &
+\multicolumn{1}{c|}{R} &
+\multicolumn{1}{c|}{V} \\
+\hline
+2 & 10 & 10 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
+\end{tabular}
+\end{center}
+}
+\vspace{-0.1in}
+\caption{Sv32 page table entry with Svpbmt.}
+\label{sv32pte}
+\end{figure*}
+
 \subsection{Virtual Address Translation Process}
 \label{sv32algorithm}

@@ -2399,7 +2499,7 @@ algorithm in Section~\ref{sv32algorithm}, except that:
 \chapter{``Svpbmt'' Standard Extension for Page-Based Memory Types, Version 1.0}
 \label{svpbmt}

-In Sv39, Sv48, and Sv57, bits 62--61 of a leaf page table entry indicate the use
+In Sv39, Sv48, and Sv57, bits 62--61 (In Sv32 bits 31--30) of a leaf page table entry indicate the use
 of page-based memory types that override the PMA(s) for the associated memory
 pages.  The encoding for the PBMT bits is captured in Table~\ref{pbmt}.

1 - 8 of 8

Previous Topic Next Topic

Home Hashtags Subgroups Terms