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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251129092527.7502-1-fangyu.yu@linux.alibaba.com>
Date: Sat, 29 Nov 2025 17:25:27 +0800
From: fangyu.yu@...ux.alibaba.com
To: rkrcmar@...tanamicro.com
Cc: ajones@...tanamicro.com,
	alex@...ti.fr,
	anup@...infault.org,
	aou@...s.berkeley.edu,
	atish.patra@...ux.dev,
	fangyu.yu@...ux.alibaba.com,
	guoren@...nel.org,
	kvm-riscv@...ts.infradead.org,
	kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-riscv-bounces@...ts.infradead.org,
	linux-riscv@...ts.infradead.org,
	palmer@...belt.com,
	pjw@...nel.org
Subject: Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

>>>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@...ux.alibaba.com> wrote:
>>>> >
>>>> > From: Fangyu Yu <fangyu.yu@...ux.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.
>

It does seem more reasonable to select the HGATP mode for each VM based
on the actual required GPA range.
I will send an updated patch based on this suggestion.

Thanks,
Fangyu