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?
