On Tue, Jul 26, 2022 at 3:25 AM Ved Shanbhogue <ved@...> wrote:

Pleas see few notes inline
regards
ved

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:

Guo Hi -

I have a few additional question

On Wed, Jul 20, 2022 at 10:20:07AM +0800, Guo Ren wrote:

I didn't mention satp or hgatp, because menvcfg.PBMTE would affect all
of them. I agree to make it more explicit:

Thanks.

This should be stated in the proposal. Please see later question about a part that
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?

1) and 2) are Okay.

I think for 2) I would suggested "reserved" instead of "ignored"

Okay

Yes, It's Sv32, and rv32 is a typo. When menvcfg/henvcfg.PBMTE is 1,
the bit 31 is treated as N-bit if the Svnapot extension is supported
else it is ignored by hardware.

I suggest reserved instead of ignored.

Okay

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.

We need care henvcfg.PBMTE to support different VM (34-bit/31-bit)
during VM context switching. VM could turn on/off menvcfg.PBMTE which
would affect its henvcfg.PBMTE.

Thanks for agreeing that a change to henvcfg.PBMTE is required. That would fix this issue.
The proposal needs to be updated with the change to henvcfg.PBMTE.

Yes, henvcfg.PBMTE is important.

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.

GPA is the virtual address, we could translate 34-bit GPA into 31-bit PA.

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.

We need henvcfg.PBMTE for V=1.

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.

menvcfg.PBMTE being 1 wouldn't let VS=1 Sv32 get the 31-bit
restricted, but the henvcfg does. I think the hypervisor could
naturally support 34-bit VM & 31-bit VM.

Yes, the proposal needs to be updated to define the henvcfg.PBMTE as affecting Sv32 behavior
when V=1.

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.

The menvcfg.PBMTE for V=1, but henvcfg.PBMTE for HS-mode. Different
VMs could have different henvcfg.PBMTE setting.

It should be the other way around - menvcfg.PBMTE affecting V=0 i.e. HS mode and
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).

regards
ved

--
Best Regards
Guo Ren