Date   

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Allen Baum
 

Note that the (unratified)  pointer masking extension would permit upper bits to be ignored (but not "simply" be ignored).


On Wed, Aug 10, 2022 at 5:26 AM Scott Johnson <scott.johnson@...> wrote:
Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.


Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Scott Johnson
 

Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.


Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Ke Chai
 

Hi Greg, 

Thanks for replying! I am sure your answer about the RISC-V Unified Discovery perfectly answered my question 2. 

In my current implementation, bit [55:50] is simply ignored, which means my PMA checker receives bits [49:0] as its input. I am asking for help because I suspect that I am doing the wrong thing. As I understand your answer, this is a possible solution, but what I really want to know is whether both measures (ignore high-order bits versus reporting PMA vacant region) are acceptable or either one is the only correct answer. The RISC-V ISA documents are really giving me little clue about this. 

Thanks again,
Ricky Chai


Greg Favor <gfavor@...> 于2022年8月10日周三 00:09写道:

On Tue, Aug 9, 2022 at 7:07 AM mark <markhimelstein@...> wrote:
On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

The way to view this matter is that PA's are full 56-bit zero-extended values.  It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access Fault on all attempted accesses with PA[55:50] != 'b000000.  That 'vacant' PMA region can of course be a "fixed" PMA region that only requires the address decode logic gates to implement.

The new (in development) RISC-V Unified Discovery mechanism will support low-level discovery of exactly things like this (and many other things).  If you're running, for example, a Linux OS, then higher-level (post OS boot) discovery would typically be provided via Device Tree of ACPI tables.

Greg



Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Greg Favor
 

On Tue, Aug 9, 2022 at 7:07 AM mark <markhimelstein@...> wrote:
On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

The way to view this matter is that PA's are full 56-bit zero-extended values.  It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access Fault on all attempted accesses with PA[55:50] != 'b000000.  That 'vacant' PMA region can of course be a "fixed" PMA region that only requires the address decode logic gates to implement.

The new (in development) RISC-V Unified Discovery mechanism will support low-level discovery of exactly things like this (and many other things).  If you're running, for example, a Linux OS, then higher-level (post OS boot) discovery would typically be provided via Device Tree of ACPI tables.

Greg



Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

mark
 


The virt-mem list is quiescent and will go away shortly. Please send questions like this to the governing committee (priv). I have plus'ed them in.

Mark

On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

Really looking forward to someone who can give me some clarification on this! 

Thank you so much,
Ricky Chai


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


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

Guo Ren
 

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


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

Greg Favor
 

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


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


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}
 


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

Guo Ren
 

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 V
By 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


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

Greg Favor
 

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.

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


Fast-track extension proposal V2 for "Sv32 Svpbmt"

Guo Ren
 

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


Fast-track extension proposal for QoS Identifiers

Ved Shanbhogue
 

Greetings !

I am sharing a link to a proposal for a Quality of Service (QoS) Identifiers extension. This proposal has been approved by the AR committee to be pursued through the fast-tack extension process.
The first part of the document provides the motivations for QoS capabilities and the QoS identifiers. The second part details the proposed S/HS privileged sqoscfg CSR to configure QoS identifiers.

Requesting feedback, questions, and comments.

regards
ved


Re: Status of v1.12 privileged specification

Greg Chadwick
 

> Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references.
It's not the only one, it's all over.   This isn't just "if it hurts when you do that, don't do that" after the fact kind of advice that is required; we need a stronger statement somewhere that clearly says that external references to the spec must not use just section numbers because they will change.

Depending on how much we rely on the git repository being the source of truth you could reference the git commit SHA-1 that was used to generate the PDF along with the more human readable document version (e.g. only include the SHA1 in a footnote or a references section).

So for say the 'misa' section of the current latest ratified privileged spec (this one https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf)  you would say something like

Section 3.1.1 'Machine ISA Register misa' of The RISC-V Instruction Set Manual Volume II: Privileged Architecture version 20211203 SHA 9896426

Obviously you would need a shorthand for that lot.


On Wed, Jul 27, 2022 at 5:47 PM Allen Baum <allen.baum@...> wrote:
Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references.
It's not the only one, it's all over.   This isn't just "if it hurts when you do that, don't do that" after the fact kind of advice that is required; we need a stronger statement somewhere that clearly says that external references to the spec must not use just section numbers because they will change.

Andrew's suggestion is a good one - but it needs to be communicated.

A slightly different issue is that these documents that this may not take into account references to extensions that have been ratified but have not been updated in the most up-to-date ratified spec yet but are in the draft). 
Maybe that problem will go away when it's all in asciidoc and updates can be made more timely.





On Tue, Jul 26, 2022 at 11:46 PM <krste@...> wrote:

There will be an annual release of all the specs, which can be
reference as Andrew says.

But, use the extension name as a key.  If the extension doesn't have a
name, we'll give it a name.

Krste

>>>>> On Tue, 26 Jul 2022 23:14:42 -0700, "Greg Favor" <gfavor@...> said:

| On Tue, Jul 26, 2022 at 10:50 PM Allen Baum <allen.baum@...> wrote:
|     So " In general every new extension will be a separate new chapter."
|     But of course, but.... will they always be added to the end of the spec, or could they be inserted into the middle?
|     The latter will, cause renumbering of chapters, and many, many references to those sections to become obsolete
|     in docs all over the ecosystem. 

|     I'm reviewing the RISC-V certification test questions, and authors must point to references for their answers.
|     If sections change numbers, then a lot of those test questions will need to be rewritten. 
|      I'm sure that won't be the only place, and tracking them all down will be a pain.

| Using chapter numbers instead of chapter titles for cross-reference purposes seems quite brittle (as you're pointing out) and undesirable.  And that constancy of all chapter (and
| section numbers) going from the 2019 Unpriv and Priv specs to the 2021 specs has already been broken.

| If it was me, I would say that the certification test questions should use chapter (and section) titles (and avoid chapter/section numbers).  Otherwise one way or another I would
| bet that their spec cross-references aren't going to survive 100% over the next 5-10 years.

| Greg


Re: Status of v1.12 privileged specification

Greg Favor
 

On Wed, Jul 27, 2022 at 9:47 AM Allen Baum <allen.baum@...> wrote:
Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references.
It's not the only one, it's all over.   This isn't just "if it hurts when you do that, don't do that" after the fact kind of advice that is required; we need a stronger statement somewhere that clearly says that external references to the spec must not use just section numbers because they will change.

Andrew's suggestion is a good one - but it needs to be communicated.

I would suggest talking with Mark to see what he thinks would be a suitable way to both document and communicate this.  It's especially not clear what would be an effective way to do the former.  Although this issue maybe folds in with the overall "RISC-V Documentation" ball of wax (which certainly will need practices to be documented and communicated).

Greg


Re: Status of v1.12 privileged specification

Allen Baum
 

Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references.
It's not the only one, it's all over.   This isn't just "if it hurts when you do that, don't do that" after the fact kind of advice that is required; we need a stronger statement somewhere that clearly says that external references to the spec must not use just section numbers because they will change.

Andrew's suggestion is a good one - but it needs to be communicated.

A slightly different issue is that these documents that this may not take into account references to extensions that have been ratified but have not been updated in the most up-to-date ratified spec yet but are in the draft). 
Maybe that problem will go away when it's all in asciidoc and updates can be made more timely.





On Tue, Jul 26, 2022 at 11:46 PM <krste@...> wrote:

There will be an annual release of all the specs, which can be
reference as Andrew says.

But, use the extension name as a key.  If the extension doesn't have a
name, we'll give it a name.

Krste

>>>>> On Tue, 26 Jul 2022 23:14:42 -0700, "Greg Favor" <gfavor@...> said:

| On Tue, Jul 26, 2022 at 10:50 PM Allen Baum <allen.baum@...> wrote:
|     So " In general every new extension will be a separate new chapter."
|     But of course, but.... will they always be added to the end of the spec, or could they be inserted into the middle?
|     The latter will, cause renumbering of chapters, and many, many references to those sections to become obsolete
|     in docs all over the ecosystem. 

|     I'm reviewing the RISC-V certification test questions, and authors must point to references for their answers.
|     If sections change numbers, then a lot of those test questions will need to be rewritten. 
|      I'm sure that won't be the only place, and tracking them all down will be a pain.

| Using chapter numbers instead of chapter titles for cross-reference purposes seems quite brittle (as you're pointing out) and undesirable.  And that constancy of all chapter (and
| section numbers) going from the 2019 Unpriv and Priv specs to the 2021 specs has already been broken.

| If it was me, I would say that the certification test questions should use chapter (and section) titles (and avoid chapter/section numbers).  Otherwise one way or another I would
| bet that their spec cross-references aren't going to survive 100% over the next 5-10 years.

| Greg


Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Guo Ren
 

On Wed, Jul 27, 2022 at 3:18 PM Andrew Waterman <andrew@...> wrote:



On Tue, Jul 26, 2022 at 11:31 PM Greg Favor <gfavor@...> wrote:

On Tue, Jul 26, 2022 at 11:08 PM Guo Ren <guoren@...> wrote:

In the current arch, the 'N' bit exists only as a function of whether the Svnapot extension is implemented or not. Otherwise it is a Reserved bit. And all this is orthogonal to bits [30:29] and whether Svpbmt is implemented or not.

Unless there is a good justifying reason to do differently in your RV32 proposal, bit [31] and bits [30:29] should not be mixed together in any manner. Their arch behaviors are orthogonal to and independent of each other.
In Sv32x4 mode, supporting Svnapot depends on PBMTE=1. Sv32x4
supporting Svnapot with PBMTE=0 is another proposal that causes
Sv32p33 (the current suggestion is Sv32p31).

Do you think the current proposal should contain Sv32p33 for Svnapot separate support?
Do we need a NAPOTE bit in m/henvcfg?

My off-hand thought is that this proposal should either support both Svnapot and Svpbmt (and always steal three PPN bits), and treat them as orthogonal extensions as in RV64. Or decide to only support Svpbmt and not have Svnapot enter the picture (and not steal a PPN bit for an 'N' bit).

It's clear to me that we should not preemptively reserve space for Svnapot in RV32. Unlike Svpbmt, it's merely an optimization, and it's a less important optimization in RV32 than in RV64. (TLB misses are cheaper because page tables are shallower; TLB misses are less frequent because data structures are smaller.)

This doesn't justify surrendering a physical address bit. Even adding an *envcfg bit is too speculative at this point. (The door's open to doing so in the future... if demand actually arises.)
Okay, my motivation is Svpbmt, not Svnapot. I agree to only introduce
[31:30] as Svpbmt in the proposal.


In either case, 2 or 3 PPN msb's are stolen and when one is doing two-stage translation, the Sv32x4 G-stage only has a 32-bit or a 31-bit GPA to translate (with the missing GPA bits presumably treated as being zeroes like in the current architecture when not all PTE PPN bits are supported).

So I guess I'm missing the need for special Sv32pXX modes. In general the stolen PPN bits are simply treated as zeroes for purposes of creating a PA or GPA.

Greg


On Tue, Jul 26, 2022 at 11:08 PM Guo Ren <guoren@...> wrote:

On Wed, Jul 27, 2022 at 10:09 AM Greg Favor <gfavor@...> wrote:

On Tue, Jul 26, 2022 at 6:38 PM Guo Ren <guoren@...> wrote:

My earlier comments were wrt PBMTE=0 and that these bits are not ignored but instead cause a Page Fault. Or did I miss that your proposal defines that bits [30:29] go back to being normal PA bits (and not reserved bits as in RV64)? In which case these bits are still not ignored.
When PBMTE=0, the [31:29] are treated as PA bits.
When PBMTE=1, the [31] is N-bit and the [30:29] is Svpbmt-bits. Even
if there is no svnapot supported, software needs to keep N-bit zero.

In the current arch, the 'N' bit exists only as a function of whether the Svnapot extension is implemented or not. Otherwise it is a Reserved bit. And all this is orthogonal to bits [30:29] and whether Svpbmt is implemented or not.

Unless there is a good justifying reason to do differently in your RV32 proposal, bit [31] and bits [30:29] should not be mixed together in any manner. Their arch behaviors are orthogonal to and independent of each other.
In Sv32x4 mode, supporting Svnapot depends on PBMTE=1. Sv32x4
supporting Svnapot with PBMTE=0 is another proposal that causes
Sv32p33 (the current suggestion is Sv32p31).

Do you think the current proposal should contain Sv32p33 for Svnapot
separate support?
Do we need a NAPOTE bit in m/henvcfg?


Greg



--
Best Regards
Guo Ren


--
Best Regards
Guo Ren


Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Andrew Waterman
 



On Tue, Jul 26, 2022 at 11:31 PM Greg Favor <gfavor@...> wrote:
On Tue, Jul 26, 2022 at 11:08 PM Guo Ren <guoren@...> wrote:
> In the current arch, the 'N' bit exists only as a function of whether the Svnapot extension is implemented or not. Otherwise it is a Reserved bit. And all this is orthogonal to bits [30:29] and whether Svpbmt is implemented or not.
>
> Unless there is a good justifying reason to do differently in your RV32 proposal, bit [31] and bits [30:29] should not be mixed together in any manner. Their arch behaviors are orthogonal to and independent of each other.
In Sv32x4 mode, supporting Svnapot depends on PBMTE=1. Sv32x4
supporting Svnapot with PBMTE=0 is another proposal that causes
Sv32p33 (the current suggestion is Sv32p31).

Do you think the current proposal should contain Sv32p33 for Svnapot separate support?
Do we need a NAPOTE bit in m/henvcfg?

My off-hand thought is that this proposal should either support both Svnapot and Svpbmt (and always steal three PPN bits), and treat them as orthogonal extensions as in RV64.  Or decide to only support Svpbmt and not have Svnapot enter the picture (and not steal a PPN bit for an 'N' bit).

It's clear to me that we should not preemptively reserve space for Svnapot in RV32.  Unlike Svpbmt, it's merely an optimization, and it's a less important optimization in RV32 than in RV64.  (TLB misses are cheaper because page tables are shallower; TLB misses are less frequent because data structures are smaller.)

This doesn't justify surrendering a physical address bit.  Even adding an *envcfg bit is too speculative at this point.  (The door's open to doing so in the future... if demand actually arises.)

In either case, 2 or 3 PPN msb's are stolen and when one is doing two-stage translation, the Sv32x4 G-stage only has a 32-bit or a 31-bit GPA to translate (with the missing GPA bits presumably treated as being zeroes like in the current architecture when not all PTE PPN bits are supported).

So I guess I'm missing the need for special Sv32pXX modes.  In general the stolen PPN bits are simply treated as zeroes for purposes of creating a PA or GPA.

Greg


On Tue, Jul 26, 2022 at 11:08 PM Guo Ren <guoren@...> wrote:
On Wed, Jul 27, 2022 at 10:09 AM Greg Favor <gfavor@...> wrote:
>
> On Tue, Jul 26, 2022 at 6:38 PM Guo Ren <guoren@...> wrote:
>>
>> > My earlier comments were wrt PBMTE=0 and that these bits are not ignored but instead cause a Page Fault. Or did I miss that your proposal defines that bits [30:29] go back to being normal PA bits (and not reserved bits as in RV64)? In which case these bits are still not ignored.
>> When PBMTE=0, the [31:29] are treated as PA bits.
>> When PBMTE=1, the [31] is N-bit and the [30:29] is Svpbmt-bits. Even
>> if there is no svnapot supported, software needs to keep N-bit zero.
>
>
> In the current arch, the 'N' bit exists only as a function of whether the Svnapot extension is implemented or not. Otherwise it is a Reserved bit. And all this is orthogonal to bits [30:29] and whether Svpbmt is implemented or not.
>
> Unless there is a good justifying reason to do differently in your RV32 proposal, bit [31] and bits [30:29] should not be mixed together in any manner. Their arch behaviors are orthogonal to and independent of each other.
In Sv32x4 mode, supporting Svnapot depends on PBMTE=1. Sv32x4
supporting Svnapot with PBMTE=0 is another proposal that causes
Sv32p33 (the current suggestion is Sv32p31).

Do you think the current proposal should contain Sv32p33 for Svnapot
separate support?
Do we need a NAPOTE bit in m/henvcfg?

>
> Greg
>
>



--
Best Regards
 Guo Ren


Re: Status of v1.12 privileged specification

Krste Asanovic
 

There will be an annual release of all the specs, which can be
reference as Andrew says.

But, use the extension name as a key. If the extension doesn't have a
name, we'll give it a name.

Krste

On Tue, 26 Jul 2022 23:14:42 -0700, "Greg Favor" <gfavor@...> said:
| On Tue, Jul 26, 2022 at 10:50 PM Allen Baum <allen.baum@...> wrote:
| So " In general every new extension will be a separate new chapter."
| But of course, but.... will they always be added to the end of the spec, or could they be inserted into the middle?
| The latter will, cause renumbering of chapters, and many, many references to those sections to become obsolete
| in docs all over the ecosystem. 

| I'm reviewing the RISC-V certification test questions, and authors must point to references for their answers.
| If sections change numbers, then a lot of those test questions will need to be rewritten. 
|  I'm sure that won't be the only place, and tracking them all down will be a pain.

| Using chapter numbers instead of chapter titles for cross-reference purposes seems quite brittle (as you're pointing out) and undesirable.  And that constancy of all chapter (and
| section numbers) going from the 2019 Unpriv and Priv specs to the 2021 specs has already been broken.

| If it was me, I would say that the certification test questions should use chapter (and section) titles (and avoid chapter/section numbers).  Otherwise one way or another I would
| bet that their spec cross-references aren't going to survive 100% over the next 5-10 years.

| Greg

|

121 - 140 of 1210