Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"
Pleas see few notes inline
On Mon, Jul 25, 2022 at 03:12:46PM +0800, Guo Ren wrote:
On Wed, Jul 20, 2022 at 9:08 PM Ved Shanbhogue <ved@...> wrote:Thanks.I didn't mention satp or hgatp, because menvcfg.PBMTE would affect all
I think for 2) I would suggested "reserved" instead of "ignored"This should be stated in the proposal. Please see later question about a part that1) and 2) are Okay.
Yes, It's Sv32, and rv32 is a typo. When menvcfg/henvcfg.PBMTE is 1,I suggest reserved instead of ignored.
Thanks for agreeing that a change to henvcfg.PBMTE is required. That would fix this issue.The hypervisor needs PBMT - for HS mode execution and so turning on/off menvcfg.PBMTE as partWe need care henvcfg.PBMTE to support different VM (34-bit/31-bit)
The proposal needs to be updated with the change to henvcfg.PBMTE.
The current proposal does not have henvcfg.PBMTE and suggested that menvcfg.PBMTE is the only control. If menvcfg.PBMTE was only control then in V=1 the Sv32 PTEs would be interpreted to have 31-bit PA and not 34-bit PA.How can a 34-bit VM be run since the act ofGPA is the virtual address, we could translate 34-bit GPA into 31-bit PA.
Yes, the proposal needs to be updated to define the henvcfg.PBMTE as affecting Sv32 behaviormenvcfg.PBMTE being 1 wouldn't let VS=1 Sv32 get the 31-bit
It should be the other way around - menvcfg.PBMTE affecting V=0 i.e. HS mode andSo I am not sure how a 34-bit VM guest can be run by thisThe menvcfg.PBMTE for V=1, but henvcfg.PBMTE for HS-mode. Different
henvcfg.PBMTE affecting V=1. So I see you are in agreement that the proposal needs to be updated to define the henvcfg.PBMTE behavior.