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

[Wu Fei]

On 10/22/25 22:26, Radim Krčmář wrote:
> 2025-10-22T21:13:08+08:00, Wu Fei <atwufei at 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 at 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.

Agreed.

> 
> And shouldn't it be invalid to pick VM_MODE_P41V39_4K when KVM is using
> Sv48x4?  

Agreed, P41 is not a good candidate for Sv48x4.

> For tests that that don't care about physical width, we could
> add:
> 
>    VM_MODE_PXXV39_4K

Intel adds VM_MODE_PXXV48_4K because "x86_64 machines are having various 
physical address width rather than some static values" according to 
commit 567a9f1e9de, and x86 has to probe the real gpa width on vm 
creation. RISC-V has 3 fixed gpa widths, so maybe we can use the 
explicit widths?

> 
> 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.

I think V48/V57 is necessary, if a machine is designed to have SV48 
guests, it's better to test it.

So is it okay to have the combination of all 9 modes?
	P(41, 50, 56) x V(39, 48, 57)
But only several ones are picked up for a specific machine, just as 
mentioned above, we won't select P41V39 for Sv48x4 etc.

Thanks,
Fei.

> 
> Thanks.