It doesn't make sense to return the recommended maximum number of
vCPUs which exceeds the maximum possible number of vCPUs.

Other architectures have already done this, such as Commit
57a2e13ebdda ("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS")

Fixes: 482795cb62aa ("LoongArch: KVM: Implement VM related functions")

Signed-off-by: Qiang Ma <maqianga@uniontech.com>
---
 arch/loongarch/kvm/vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
index 8cc5ee1c53ef..1317c718f896 100644
--- a/arch/loongarch/kvm/vm.c
+++ b/arch/loongarch/kvm/vm.c
@@ -125,7 +125,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		r = 1;
 		break;
 	case KVM_CAP_NR_VCPUS:
-		r = num_online_cpus();
+		r = min_t(unsigned int, num_online_cpus(), KVM_MAX_VCPUS);
 		break;
 	case KVM_CAP_MAX_VCPUS:
 		r = KVM_MAX_VCPUS;
-- 
2.20.1

On 2026/4/28 下午3:47, Qiang Ma wrote:
> It doesn't make sense to return the recommended maximum number of
> vCPUs which exceeds the maximum possible number of vCPUs.
> 
> Other architectures have already done this, such as Commit
> 57a2e13ebdda ("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS")
> 
> Fixes: 482795cb62aa ("LoongArch: KVM: Implement VM related functions")
> 
> Signed-off-by: Qiang Ma <maqianga@uniontech.com>
> ---
>   arch/loongarch/kvm/vm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
> index 8cc5ee1c53ef..1317c718f896 100644
> --- a/arch/loongarch/kvm/vm.c
> +++ b/arch/loongarch/kvm/vm.c
> @@ -125,7 +125,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>   		r = 1;
>   		break;
>   	case KVM_CAP_NR_VCPUS:
> -		r = num_online_cpus();
> +		r = min_t(unsigned int, num_online_cpus(), KVM_MAX_VCPUS);
>   		break;
>   	case KVM_CAP_MAX_VCPUS:
>   		r = KVM_MAX_VCPUS;
> 
Hi Qiang,

yes, this is better.

Though value of CONFIG_NR_CPUS is 2048, currently max CPU number of host 
hardware is 256 still because of limitation of AVEC and extioi HW irqchip.

If there is HW machine in future which supports more than 256 CPUs, the 
max online CPU is no more than 256 with existing kernel version. So I 
think that the "Fixes" tag is not necessary.

Reviewed-by: Bibo Mao <maobibo@loongson.cn>

在 2026/4/28 17:50, Bibo Mao 写道:
>
>
> On 2026/4/28 下午3:47, Qiang Ma wrote:
>> It doesn't make sense to return the recommended maximum number of
>> vCPUs which exceeds the maximum possible number of vCPUs.
>>
>> Other architectures have already done this, such as Commit
>> 57a2e13ebdda ("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS")
>>
>> Fixes: 482795cb62aa ("LoongArch: KVM: Implement VM related functions")
>>
>> Signed-off-by: Qiang Ma <maqianga@uniontech.com>
>> ---
>>   arch/loongarch/kvm/vm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
>> index 8cc5ee1c53ef..1317c718f896 100644
>> --- a/arch/loongarch/kvm/vm.c
>> +++ b/arch/loongarch/kvm/vm.c
>> @@ -125,7 +125,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, 
>> long ext)
>>           r = 1;
>>           break;
>>       case KVM_CAP_NR_VCPUS:
>> -        r = num_online_cpus();
>> +        r = min_t(unsigned int, num_online_cpus(), KVM_MAX_VCPUS);
>>           break;
>>       case KVM_CAP_MAX_VCPUS:
>>           r = KVM_MAX_VCPUS;
>>
> Hi Qiang,
>
> yes, this is better.
>
> Though value of CONFIG_NR_CPUS is 2048, currently max CPU number of 
> host hardware is 256 still because of limitation of AVEC and extioi HW 
> irqchip.
>
> If there is HW machine in future which supports more than 256 CPUs, 
> the max online CPU is no more than 256 with existing kernel version. 
> So I think that the "Fixes" tag is not necessary.
That makes sense. Let's remove the "Fixes" tag and send out the v2 version.
>
> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
>
>