Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

["Radim Krčmář" <rkrcmar@ventanamicro.com>]

2025-11-25T22:18:11+08:00, <fangyu.yu@linux.alibaba.com>:
>>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>>> >
>>> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>>> >
>>> > Currently, HGATP mode uses the maximum value detected by the hardware
>>> > but often such a wide GPA is unnecessary, just as a host sometimes
>>> > doesn't need sv57.
>>> > It's likely that no additional parameters (like no5lvl and no4lvl) are
>>> > needed, aligning HGATP mode to SATP mode should meet the requirements
>>> > of most scenarios.
>>> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
>>> reasonable.
>>
>>The documentation should be improved, but I don't think we want to state
>>that these parameters apply to both s- and g-stage. If we need parameters
>>to dictate KVM behavior (g-stage management), then we should add KVM
>>module parameters.
>
> Right, adding new parameters for g-stage management is clear.
>
> Or we could discuss this topic, from a virtual machine perspective,
> it may not be necessary to provide all hardware configuration
> combinations. For example, when SATP is configured as sv48,
> configuring HGATP as sv57*4 is not very meaningful, Because the
> VM cannot actually use more than 48 bits of GPA range.

The choice of hgatp mode depends on how users configure guest's memory
map, regardless of what satp or vsatp modes are.
(All RV64 SvXY modes map XY bit VA to 56 bit PA.)

If the machine model maps memory with set bit 55, then KVM needs to
configure Sv57x4, and if nothing is mapped above 2 TiB, then KVM is
completely fine with Sv39x4.

A module parameter works, but I think it would be nicer to set the hgatp
mode per-VM, because most VMs could use the efficient Sv39x4, while it's
not a good idea to pick it as the default.
I think KVM has enough information to do it automatically (and without
too much complexity) by starting with Sv39x4, and expanding as needed.

Thanks.