On Wed, Jul 27, 2022 at 12:38 AM Greg Favor <gfavor@...> wrote:
On Tue, Jul 26, 2022 at 6:47 AM Guo Ren <guoren@...> wrote:
Note that in general reserved PTE bits that are non-zero - whether due to the bit still simply being reserved, or it corresponding to an unimplemented extension or to a disabled extension (via *envcfg) - result in a Page Fault exception, i.e. they are not ignored.
The bit 31-29 of any Sv32x4 PTE isn't addressing bits when menvcfg.PBMTE is 1.
Okay?
First note that the Svpbmt extension and associated PBMTE bits only affects two bits in a PTE - namely bits [30:29] in your proposal. It has no effect on bit [31] (the 'N' bit) - which is a function of whether the Svnapot extension is supported.
If menvcfg.PBMTE is 1 (which also implies that the Svpbmt extension is supported), then bits [30:29] have the meaning defined by Svpbmt (Although the '11' encoding is reserved and causes a Page Fault.)
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.
