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,

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

Yes.

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
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
\end{commentary}

Same comment as above.

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

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

| 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

Yes.

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
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
\end{commentary}

Same comment as above.

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

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

| 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

Yes.

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
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
\end{commentary}

Same comment as above.

| 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

\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

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
PBMT. When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual
\end{commentary}

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

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

\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:

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

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

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

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

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}

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

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

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

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

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

| 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}
+\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}
+\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*}
+
\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.

regards
ved

Re: Status of v1.12 privileged specification

> 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