KVM: riscv: selftests: sv39 support needed?

[Wu Fei]

On 10/9/25 22:40, Andrew Jones wrote:
> On Thu, Oct 09, 2025 at 08:40:03PM +0800, Wu Fei wrote:
>>
>> On 9/18/25 22:13, Andrew Jones wrote:
>>> On Wed, Sep 17, 2025 at 10:11:05AM +0800, wu.fei9 at sanechips.com.cn wrote:
>>>> I was running kvm selftests on qemu-system-riscv64 with "-cpu rva23s64", which
>>>> uses sv39 by default, then I got the following error. After some debugging I
>>>> found sv39 is not supported for selftests, should we add sv39 support? I can
>>>> prepare a patch if it's needed.
>>> Yes, please.
>>
>>
>> Should we add another mode as VM_MODE_P41V39_4K? The smallest VA is 47bits
>> on the existing modes.
> 
> Why P41? sv39 supports a 56-bit physical address. To support sv39 I'd
> expect to add a VM_MODE_P56V39_4K. And, afaict, the reason we don't have a
> VM_MODE_P56V48_4K is simply because when riscv support was added it
> didn't add any new modes. We could VM_MODE_P56V48_4K as part of this work.

It's about mode for guest? Which is also limited by hgapt.mode, suppose 
hgapt.mode is Sv39x4, the valid gpa bits is 41.

> 
>>
>> Also, is it necessary to add mode for sv57? Or we can just use some existing
>> ones such as P52V48 instead.
> 
> We need new modes that support 57-bit virtual addresses to test that
> support, and I'd like to see that. Again we have a 56-bit physical
> address, so the new mode would be VM_MODE_P56V57_4K.
> 
>>
>>>
>>>> # ./arch_timer
>>>> Random seed: 0x6b8b4567
>>>> ==== Test Assertion Failure ====
>>>>     arch_timer.c:73: false
>>>>     pid=144 tid=146 errno=0 - Success
>>> We can avoid errors for the default case by adding a
>>> kvm_selftest_arch_init() function for riscv which calls
>>> guest_modes_append_default(). We'll also need to modify
>>> guest_modes_append_default() to configure the default using information
>>> from KVM that can be obtained with a get-one-reg of the satp_mode config
>>> register. OIOW, use satp_mode but otherwise just mimic arm64's setup.
>>
>>
>> Is the current kvm_check_cap(KVM_CAP_VM_GPA_BITS) equal to satp_mode,
>>
>> e.g. gpa 41-bits always means 8 in satp_mode?
> 
> No, KVM_CAP_VM_GPA_BITS only tells you the number of physical bits of the
> host, which dictates the maximum mode you can choose (see
> lib/guest_modes.c). You can get the maximum satp_mode with get-one-reg
> RISCV_CONFIG_REG(satp_mode) and then use that or anything smaller than
> that for the mode in the test. See lib/guest_modes.c again to see how
> there's support in the test framework for looping over modes in order to
> run the same tests on multiple modes. To do that, the test will change
> the guest configured mode with a set-one-reg of satp_mode.

Got it, just check the difference of the two methods:
* KVM_CAP_VM_GPA_BITS - value from hgatp.mode, which is set during 
kvm_riscv_gstage_mode_detect(), represents the hardware capability
* RISCV_CONFIG_REG(satp_mode) - value from satp_mode, which is set 
during set_satp_mode(), decided by both hardware capability and kernel 
cmdline

It looks like current implementation tries to ensure vsatp.mode equals 
to host satp.mode (I don't think it's necessary from spec point of 
view), so that only one mode can be set for guest, in 
kvm_riscv_vcpu_set_reg_config:

         case KVM_REG_RISCV_CONFIG_REG(satp_mode):
                 if (reg_val != (satp_mode >> SATP_MODE_SHIFT))
                         return -EINVAL;
                 break;

Thanks,
Fei.

> 
> Thanks,
> drew