1. Tech-Privileged
  2. Messages

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

Greg Favor
 

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

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
Join tech-privileged@lists.riscv.org to automatically receive all group messages.