Re: [PATCH 2/2] KVM: riscv: selftests: Detect supported vm modes

From: "Radim Krčmář" <rkrcmar@ventanamicro.com>
To: "Wu Fei" <atwufei@163.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	<wu.fei9@sanechips.com.cn>
Cc: <kvm-riscv@lists.infradead.org>,
	"kvm-riscv" <kvm-riscv-bounces@lists.infradead.org>
Subject: Re: [PATCH 2/2] KVM: riscv: selftests: Detect supported vm modes
Date: Mon, 20 Oct 2025 21:32:57 +0200	[thread overview]
Message-ID: <DDNEF8ASSO19.2P4OJ3KYPWRIH@ventanamicro.com> (raw)
In-Reply-To: <93d3af21-5d3d-465c-a9f2-0eaed7475fb3@163.com>

2025-10-20T21:26:18+08:00, Wu Fei <atwufei@163.com>:
> On 10/18/25 00:04, Andrew Jones wrote:
>>> -               guest_mode_append(VM_MODE_P56V57_4K, sz >= 59);
>>> -               guest_mode_append(VM_MODE_P50V48_4K, sz >= 50);
>>> -               guest_mode_append(VM_MODE_P41V39_4K, sz >= 41);
>>> +               guest_mode_append(VM_MODE_P56V57_4K, satp_mode >= SATP_MODE_57 && sz >= 59);
>>> +               guest_mode_append(VM_MODE_P50V48_4K, satp_mode >= SATP_MODE_48 && sz >= 50);
>>> +               guest_mode_append(VM_MODE_P41V39_4K, satp_mode >= SATP_MODE_39 && sz >= 41);
>> 
>> Something along these lines was what I was suggesting in the last patch,
>> but where we select from many more combinations of P and V for modes.
>>
>> VM_MODE_P41V39_4K
>> VM_MODE_P41V48_4K
>> VM_MODE_P41V57_4K
>> VM_MODE_P50V48_4K
>> VM_MODE_P50V57_4K
>> VM_MODE_P59V57_4K
>
> Do we need more? e.g. for sv39, there could be P50V39 and P56V39.

Bare is probably the most important first stage mode, as it's the only
one that might fully test the two extra bits of Sv57x4.

I think a single combination per "x4" mode might be sufficient, since
all non-bare first stages generate 56-bit physical addresses anyway, but
it makes sense to have all of them if we're doing more than one.

>> 
>>> +
>>> +               // set the first (maximum) supported mode as default
>> 
>> Please, no C++ comments, and don't we want a V39 mode to be the default?
>> In fact, VM_MODE_P41V39_4K should always be supported, so we can just set
>> VM_MODE_DEFAULT to that.
>
> It's likely the maximum supported mode is the most common configuration 
> on production?

Yes, KVM currently picks the widest mode, although I think the optimal
choice of hgatp is the smallest one that fully covers the whole guest
physical address space.

(e.g. if all guest memory is mapped below 2 TiB, KVM should pick Sv39x4
 for its hgatp, regardless of what is the widest supported mode.)

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