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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAAhSdy0SU86SeAN+NHoYKUubfG8Z3nonge86kzvfdupWWc4-qA@mail.gmail.com>
Date: Wed, 3 Dec 2025 11:38:57 +0530
From: Anup Patel <anup@...infault.org>
To: Guo Ren <guoren@...nel.org>
Cc: Radim Krčmář <rkrcmar@...tanamicro.com>, 
	fangyu.yu@...ux.alibaba.com, ajones@...tanamicro.com, alex@...ti.fr, 
	aou@...s.berkeley.edu, atish.patra@...ux.dev, kvm-riscv@...ts.infradead.org, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, palmer@...belt.com, pjw@...nel.org, 
	linux-riscv <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

On Thu, Nov 27, 2025 at 7:09 AM Guo Ren <guoren@...nel.org> wrote:
>
>
>
> On Wed, Nov 26, 2025 at 2:16 AM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>>
>> 2025-11-25T22:18:11+08:00, <fangyu.yu@...ux.alibaba.com>:
>> >>> 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.
>
> 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