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

[Wu Fei]

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

> 
>>
>>>>
>>>>> +
>>>>> +               // 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.)
> 
> Yes, and for the tests, I think the guest config can just default to the
> minimal. Tests that need particular modes can select them when supported.
> We ensure tests run the same code on all hosts this way when the mode
> selected isn't what's under test.

OK.

Thanks,
Fei.

> 
> Thanks,
> drew