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