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>
Cc: <wu.fei9@sanechips.com.cn>, <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: Wed, 22 Oct 2025 16:26:20 +0200	[thread overview]
Message-ID: <DDOX5JZWQK87.2SZ1CS39ZZAOZ@ventanamicro.com> (raw)
In-Reply-To: <5ed53d05-2ed8-43dc-8a41-1906b6982c80@163.com>

2025-10-22T21:13:08+08:00, Wu Fei <atwufei@163.com>:
> On 10/22/25 07:55, Andrew Jones wrote:
>> On Mon, Oct 20, 2025 at 09:32:57PM +0200, Radim Krčmář wrote:
>>> 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.
>> 
>> Indeed, but for that we need a mode named something like VM_MODE_BARE59.
>
> The current code has some assumption on non-bare mode, such as virt_map. 
> It looks not trivial to support BARE mode. Is it okay to focus on 
> non-bare mode in this series, and leave bare mode support to another 
> patchset?>

Of course.  There is no point in adding symbols that are not used.

>>> 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.
>> 
>> Yeah, might as well.
>
> Add all of them?

Tests cannot choose hgatp; KVM just tells us that the physical width is.
This means that we must support the following:

  VM_MODE_P41V39_4K
  VM_MODE_P50V39_4K
  VM_MODE_P59V39_4K

I don't think it's correct to assume that when SvABx4 is supported, then
SvAB is supported, hence we must have Sv39 for each hgatp mode that KVM
supports.

And shouldn't it be invalid to pick VM_MODE_P41V39_4K when KVM is using
Sv48x4?  For tests that that don't care about physical width, we could
add:

  VM_MODE_PXXV39_4K

It doesn't seem necessary to support more than that, but if our tests
want larger virtual address space, we can add V48 and V57 variants.

Thanks.

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