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

From: Anup Patel <anup@brainfault.org>
To: Guo Ren <guoren@kernel.org>
Cc: "Radim Krčmář" <rkrcmar@ventanamicro.com>,
	fangyu.yu@linux.alibaba.com, ajones@ventanamicro.com,
	alex@ghiti.fr, aou@eecs.berkeley.edu, atish.patra@linux.dev,
	kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	palmer@dabbelt.com, pjw@kernel.org,
	linux-riscv <linux-riscv-bounces@lists.infradead.org>
Subject: Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode
Date: Wed, 3 Dec 2025 11:38:57 +0530	[thread overview]
Message-ID: <CAAhSdy0SU86SeAN+NHoYKUubfG8Z3nonge86kzvfdupWWc4-qA@mail.gmail.com> (raw)
In-Reply-To: <CAJF2gTTYwsG4Q6n3JWi8S4brOA_mh7OdpquMU-eJYAEHwDeSdw@mail.gmail.com>

On Thu, Nov 27, 2025 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
>
>
>
> On Wed, Nov 26, 2025 at 2:16 AM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>>
>> 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.
>
> Good point; if only a 128GB GPA memory region is needed, there is no need for Sv57x4, which costs PTW cycles.
>
> So, the detection should start from Sv39x4 to Sv57x4 with the guest memory size.
>

NACK to the approach of detecting backwards.

HGATP mode is a per-VM attribute hence it makes sense
to define a VM-level KVM_CAP_RISC_xyz for this purpose.
The default behaviour should be use highest HGATP mode
unless KVM user-space changes the KVM_CAP_RISC_xyz
setting.

---
Anup

-- 
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv