2016-05-03 06:52+0200, Greg Kurz: > The KVM_MAX_VCPUS define provides the maximum number of vCPUs per guest, and > also the upper limit for vCPU ids. This is okay for all archs except PowerPC > which can have higher ids, depending on the cpu/core/thread topology. In the > worst case (single threaded guest, host with 8 threads per core), it limits > the maximum number of vCPUS to KVM_MAX_VCPUS / 8. > > This patch separates the vCPU numbering from the total number of vCPUs, with > the introduction of KVM_MAX_VCPU_ID, as the maximal valid value for vCPU ids > plus one. > > The corresponding KVM_CAP_MAX_VCPU_ID allows userspace to validate vCPU ids > before passing them to KVM_CREATE_VCPU. > > Only PowerPC gets unlimited vCPU ids for the moment. This patch doesn't > change anything for other archs. > > Suggested-by: Radim Krcmar <rkrcmar@xxxxxxxxxx> > Signed-off-by: Greg Kurz <gkurz@xxxxxxxxxxxxxxxxxx> > --- > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > @@ -2272,7 +2272,7 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id) > int r; > struct kvm_vcpu *vcpu; > > - if (id >= KVM_MAX_VCPUS) > + if (id >= KVM_MAX_VCPU_ID) > return -EINVAL; book3s_hv will currently fail with vcpu_id above threads_per_subcore * KVM_MAX_VCORES, so userspace cannot use KVM_CAP_MAX_VCPU_ID to limit vcpu_id ... I thought the check for vcpu_id would move to arch-specific code, like the previous version did, to simplify implementation of a dynamic limit. The dynamic limit was too complicated to be worth it? (This version is ok too.)
