On Tue, Jul 26, 2022 at 3:25 AM Ved Shanbhogue <ved@...> wrote:
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
Guo Hi -
I have a few additional question
On Wed, Jul 20, 2022 at 10:20:07AM +0800, Guo Ren wrote:
of them. I agree to make it more explicit:
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.
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?
Yes, It's Sv32, and rv32 is a typo. When menvcfg/henvcfg.PBMTE is 1,I suggest reserved instead of ignored.
the bit 31 is treated as N-bit if the Svnapot extension is supported
else it is ignored by hardware.
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)
of VM context switching is not an option.
during VM context switching. VM could turn on/off menvcfg.PBMTE which
would affect its henvcfg.PBMTE.
The proposal needs to be updated with the change to henvcfg.PBMTE.
Yes, henvcfg.PBMTE is important.
The current proposal does not have henvcfg.PBMTE and suggested that menvcfg.PBMTE is the
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.
setting menvcfg.PBMTE forces the Sv32 to work in 31-bit restricted mode.
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.
We need henvcfg.PBMTE for V=1.
Yes, the proposal needs to be updated to define the henvcfg.PBMTE as affecting Sv32 behavior
menvcfg.PBMTE being 1 wouldn't let VS=1 Sv32 get the 31-bit
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.
restricted, but the henvcfg does. I think the hypervisor could
naturally support 34-bit VM & 31-bit VM.
It should be the other way around - menvcfg.PBMTE affecting V=0 i.e. HS mode and
So 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
hypervisor. The same VM can run natively by having menvcfg.PBMTE set to 0.
VMs could have different henvcfg.PBMTE setting.
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.
Yes, you are right (menvcfg.PBMTE for V=0, and henvcfg.PBMTE is for V=1)
When menvcfg.PBMTE = 1, henvcfg.PBMTE could be 1 or 0.
WHen menvcfg.PBMTE = 0, henvcfg.PBMTE is fixed 0 (SW set 1 would still cause 0).