Guo Hi -
I have a few additional question
On Wed, Jul 20, 2022 at 10:20:07AM +0800, Guo Ren wrote:
I see you mentioned Sv32 implementations. I am reading it literally as Sv32 as in1. Treatment of Sv32x4 when mencvcfg.PBMT is set is not mentioned. Is thatI've mentioned that, and you missed it.
one of the presently defined modes of satp. I dont see anywhere in the text a mention
of hgatp or Sv32x4. If you did intend that then it is extremely subtle. Could it be made more explicit. Further the behavior that bit 31 of Sv32x4 PTE becomes ignored
when menvcfg.PBMTE is 1 is important to call out.
This should be stated in the proposal. Please see later question about a part that3. If menvcfg.PBMT is set but henvcfg.PBMT is not set is it expected that non-zeroSelect 2), not 30:29. But GUEST.PTE.PPN is 31:20, and
supports Sv32, Svpbmt but not Svnapot. Selecting 2) with bit 31 included makes the bit 31
not reserved on this part even though part does not support Svnapot. So may be it
should be stated in two parts 1) setting menvcfg.PBMTE makes bits 30:29 usable as PBMT bit
and restricts the physical width to 31 bits. 2) The bit 31 is treated as N bit if the the Svnapot extension is supported else it is ignore by hardware. Is that right?
By currently, I think you mean "as currently proposed by this extension". Right?4. If menvcfg.PBMT is set but henvcfg.PBMT is not set what is treatment of N bit.Currently, Svnapot is also enabled by menvcfg.PBMTE for rv32.
The change in the meaning of PBMTE bit definition to act as a Svnapot enabled but only
for Sv32 is new. You mentioned "for rv32". Was this intentional that this
would be restricted to rv32 or is a behavior of the Sv32 mode and not restricted to rv32?
So when menvcfg.PBMTE is 1, then Sv32 behavior changes and becomes 31-bit restricted.5. If a hypervisor had a legacy 34-bit VM and hypervisor used say Sv39 and menvcfg.PBMTYour question is how to support "existing 34-bit VMs with new 31-bit
The hypervisor needs PBMT - for HS mode execution and so turning on/off menvcfg.PBMTE as part of VM context switching is not an option. How can a 34-bit VM be run since the act of setting menvcfg.PBMTE forces the Sv32 to work in 31-bit restricted mode.
This is not relevant to what I asked (orthogonally;for completeness that list should also include NC).
My question was how can one execute a VM that needs 34-bit GPA on a hypervisor that uses
Sv39 for its S-stage and uses PBMTE. So the hypervisors S-stage page tables are Sv39 and since it
needs to use PBMT, menvcfg.PBMTE is set to 1. This hypervisor when it does an sret to V=1 mode of execution and if the VS uses Sv32 then due to menvcfg.PBMTE being 1 it will get the 31-bit restricted behavior. So I am not sure how a 34-bit VM guest can be run by this hypervisor. The same VM can run natively by having menvcfg.PBMTE set to 0.
I think there is more than width reduction - there is also the new behavior of the bit acting as a enable for Svnapot. Further on a part that support Svpbmt but not Svnapot this bit now has the behavior of making bit 31 of the PTE a ignored bit.7. The privilege chapters that discuss the [m|h]envcfg.PBMTE bit need to be updated withDo you mean add: