[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251125141811.39964-1-fangyu.yu@linux.alibaba.com>
Date: Tue, 25 Nov 2025 22:18:11 +0800
From: fangyu.yu@...ux.alibaba.com
To: ajones@...tanamicro.com
Cc: 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@...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.
Thanks,
Fangyu
>Thanks,
>drew
Powered by blists - more mailing lists