Re: [PATCH v5 5/9] KVM: selftests: Make kvm_create_max_vcpus tolerate ENOMEM

[IBM]

Sean Christopherson <seanjc@xxxxxxxxxx> writes:

> On Tue, Sep 22, 2026, Ritesh Harjani (IBM) wrote:
>> diff --git a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
>> index 59ddc3757943..45a9d8b369b5 100644
>> --- a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
>> +++ b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
>> @@ -20,16 +20,29 @@
>>  void test_vcpu_creation(int first_vcpu_id, int num_vcpus)
>>  {
>>  	struct kvm_vm *vm;
>> -	int i;
>> +	struct kvm_vcpu *vcpu;
>> +	int i, created = 0;
>>  
>>  	pr_info("Testing creating %d vCPUs, with IDs %d...%d.\n",
>>  		num_vcpus, first_vcpu_id, first_vcpu_id + num_vcpus - 1);
>>  
>>  	vm = vm_create_barebones();
>>  
>> -	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++)
>> -		/* This asserts that the vCPU was created. */
>> -		__vm_vcpu_add(vm, i);
>> +	for (i = first_vcpu_id; i < first_vcpu_id + num_vcpus; i++) {
>> +		vcpu = __vm_vcpu_try_add(vm, i);
>> +		if (vcpu) {
>> +			created++;
>> +			continue;
>> +		}
>
> Oof.  I dislike this, to put it very mildly.  Is this the KVM_CAP_PPC_SMT thing
> again, or something else?
>

No, this is not the SMT issue, where PowerPC encodes topology in the id,
so we cannot use the full MAX_VCPU_ID range without a valid SMT layout.
That problem we have fixed in Patch-2.

This is resource limitation on L0 Hypervisor for KVM-on-PowerVM
(nestedv2) case. On nestedv2, KVM_CREATE_VCPU is an hcall to the PowerVM
hypervisor (H_GUEST_CREATE_VCPU). Now MAX_VCPUS or the MAX_VCPU_ID are
the max vcpuid range limits, but that is not a promise. L0 can still run
out of guest management space, i.e. the hcall can fail with
H_Not_Enough_Resources error as per platform HCALL specification.
KVM maps this hcall's out of resource error to -ENOMEM.

> Assuming it's KVM_CAP_PPC_SMT, is there really no way userspace can pre-probe the
> "real" limit?  Or modify the test to enable KVM_CAP_PPC_SMT and do the proper
> striding?  Eating -ENOMEM is all kinds of gross, and I really don't want to add
> __vm_vcpu_try_add().

We already probed for max vcpu id range limit. I don't think userspace
can probe for anything else here. But let me think about this a bit and
get back. Maybe I can see if I can drop the helper.

-ritesh