| Message ID | 20190523164309.13345-9-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | KVM selftests for s390x | expand |
On Thu, May 23, 2019 at 06:43:08PM +0200, Thomas Huth wrote: > KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all > architectures. However, on s390x, the amount of usable CPUs is determined > during runtime - it is depending on the features of the machine the code > is running on. Since we are using the vcpu_id as an index into the SCA > structures that are defined by the hardware (see e.g. the sca_add_vcpu() > function), it is not only the amount of CPUs that is limited by the hard- > ware, but also the range of IDs that we can use. > Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. > So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common > code into the architecture specific code, and on s390x we have to return > the same value here as for KVM_CAP_MAX_VCPUS. > This problem has been discovered with the kvm_create_max_vcpus selftest. > With this change applied, the selftest now passes on s390x, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > arch/mips/kvm/mips.c | 3 +++ > arch/powerpc/kvm/powerpc.c | 3 +++ > arch/s390/kvm/kvm-s390.c | 1 + > arch/x86/kvm/x86.c | 3 +++ > virt/kvm/arm/arm.c | 3 +++ > virt/kvm/kvm_main.c | 2 -- > 6 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c > index 6d0517ac18e5..0369f26ab96d 100644 > --- a/arch/mips/kvm/mips.c > +++ b/arch/mips/kvm/mips.c > @@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MIPS_FPU: > /* We don't handle systems with inconsistent cpu_has_fpu */ > r = !!raw_cpu_has_fpu; > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > index 3393b166817a..aa3a678711be 100644 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > #ifdef CONFIG_PPC_BOOK3S_64 > case KVM_CAP_PPC_GET_SMMU_INFO: > r = 1; > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index 8d6d75db8de6..871d2e99b156 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_NR_VCPUS: > case KVM_CAP_MAX_VCPUS: > + case KVM_CAP_MAX_VCPU_ID: > r = KVM_S390_BSCA_CPU_SLOTS; > if (!kvm_s390_use_sca_entries()) > r = KVM_MAX_VCPUS; > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 536b78c4af6e..09a07d6a154e 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_PV_MMU: /* obsolete */ > r = 0; > break; > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 90cedebaeb94..7eeebe5e9da2 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MSI_DEVID: > if (!kvm) > r = -EINVAL; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index f0d13d9d125d..c09259dd6286 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > case KVM_CAP_MULTI_ADDRESS_SPACE: > return KVM_ADDRESS_SPACE_NUM; > #endif > - case KVM_CAP_MAX_VCPU_ID: > - return KVM_MAX_VCPU_ID; > case KVM_CAP_NR_MEMSLOTS: > return KVM_USER_MEM_SLOTS; > default: > -- > 2.21.0 > Reviewed-by: Andrew Jones <drjones@redhat.com>
On Thu, 23 May 2019 18:43:08 +0200 Thomas Huth <thuth@redhat.com> wrote: In the subject: s/unusabled/unusable/ > KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all > architectures. However, on s390x, the amount of usable CPUs is determined > during runtime - it is depending on the features of the machine the code > is running on. Since we are using the vcpu_id as an index into the SCA > structures that are defined by the hardware (see e.g. the sca_add_vcpu() > function), it is not only the amount of CPUs that is limited by the hard- > ware, but also the range of IDs that we can use. > Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. > So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common > code into the architecture specific code, and on s390x we have to return > the same value here as for KVM_CAP_MAX_VCPUS. > This problem has been discovered with the kvm_create_max_vcpus selftest. > With this change applied, the selftest now passes on s390x, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > arch/mips/kvm/mips.c | 3 +++ > arch/powerpc/kvm/powerpc.c | 3 +++ > arch/s390/kvm/kvm-s390.c | 1 + > arch/x86/kvm/x86.c | 3 +++ > virt/kvm/arm/arm.c | 3 +++ > virt/kvm/kvm_main.c | 2 -- > 6 files changed, 13 insertions(+), 2 deletions(-) Reviewed-by: Cornelia Huck <cohuck@redhat.com>
On 23.05.19 18:43, Thomas Huth wrote: > KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all > architectures. However, on s390x, the amount of usable CPUs is determined > during runtime - it is depending on the features of the machine the code > is running on. Since we are using the vcpu_id as an index into the SCA > structures that are defined by the hardware (see e.g. the sca_add_vcpu() > function), it is not only the amount of CPUs that is limited by the hard- > ware, but also the range of IDs that we can use. > Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. > So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common > code into the architecture specific code, and on s390x we have to return > the same value here as for KVM_CAP_MAX_VCPUS. > This problem has been discovered with the kvm_create_max_vcpus selftest. > With this change applied, the selftest now passes on s390x, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > arch/mips/kvm/mips.c | 3 +++ > arch/powerpc/kvm/powerpc.c | 3 +++ > arch/s390/kvm/kvm-s390.c | 1 + > arch/x86/kvm/x86.c | 3 +++ > virt/kvm/arm/arm.c | 3 +++ > virt/kvm/kvm_main.c | 2 -- > 6 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c > index 6d0517ac18e5..0369f26ab96d 100644 > --- a/arch/mips/kvm/mips.c > +++ b/arch/mips/kvm/mips.c > @@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MIPS_FPU: > /* We don't handle systems with inconsistent cpu_has_fpu */ > r = !!raw_cpu_has_fpu; > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > index 3393b166817a..aa3a678711be 100644 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > #ifdef CONFIG_PPC_BOOK3S_64 > case KVM_CAP_PPC_GET_SMMU_INFO: > r = 1; > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index 8d6d75db8de6..871d2e99b156 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_NR_VCPUS: > case KVM_CAP_MAX_VCPUS: > + case KVM_CAP_MAX_VCPU_ID: > r = KVM_S390_BSCA_CPU_SLOTS; > if (!kvm_s390_use_sca_entries()) > r = KVM_MAX_VCPUS; > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 536b78c4af6e..09a07d6a154e 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_PV_MMU: /* obsolete */ > r = 0; > break; > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 90cedebaeb94..7eeebe5e9da2 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MSI_DEVID: > if (!kvm) > r = -EINVAL; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index f0d13d9d125d..c09259dd6286 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > case KVM_CAP_MULTI_ADDRESS_SPACE: > return KVM_ADDRESS_SPACE_NUM; > #endif > - case KVM_CAP_MAX_VCPU_ID: > - return KVM_MAX_VCPU_ID; > case KVM_CAP_NR_MEMSLOTS: > return KVM_USER_MEM_SLOTS; > default: > Reviewed-by: David Hildenbrand <david@redhat.com>
Paolo, Radim, would you consider this patch (or the full series) as 5.2 material or 5.3 material? On 23.05.19 18:43, Thomas Huth wrote: > KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all > architectures. However, on s390x, the amount of usable CPUs is determined > during runtime - it is depending on the features of the machine the code > is running on. Since we are using the vcpu_id as an index into the SCA > structures that are defined by the hardware (see e.g. the sca_add_vcpu() > function), it is not only the amount of CPUs that is limited by the hard- > ware, but also the range of IDs that we can use. > Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. > So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common > code into the architecture specific code, and on s390x we have to return > the same value here as for KVM_CAP_MAX_VCPUS. > This problem has been discovered with the kvm_create_max_vcpus selftest. > With this change applied, the selftest now passes on s390x, too. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > arch/mips/kvm/mips.c | 3 +++ > arch/powerpc/kvm/powerpc.c | 3 +++ > arch/s390/kvm/kvm-s390.c | 1 + > arch/x86/kvm/x86.c | 3 +++ > virt/kvm/arm/arm.c | 3 +++ > virt/kvm/kvm_main.c | 2 -- > 6 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c > index 6d0517ac18e5..0369f26ab96d 100644 > --- a/arch/mips/kvm/mips.c > +++ b/arch/mips/kvm/mips.c > @@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MIPS_FPU: > /* We don't handle systems with inconsistent cpu_has_fpu */ > r = !!raw_cpu_has_fpu; > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > index 3393b166817a..aa3a678711be 100644 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > #ifdef CONFIG_PPC_BOOK3S_64 > case KVM_CAP_PPC_GET_SMMU_INFO: > r = 1; > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index 8d6d75db8de6..871d2e99b156 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_NR_VCPUS: > case KVM_CAP_MAX_VCPUS: > + case KVM_CAP_MAX_VCPU_ID: > r = KVM_S390_BSCA_CPU_SLOTS; > if (!kvm_s390_use_sca_entries()) > r = KVM_MAX_VCPUS; > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 536b78c4af6e..09a07d6a154e 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_PV_MMU: /* obsolete */ > r = 0; > break; > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 90cedebaeb94..7eeebe5e9da2 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_MAX_VCPUS: > r = KVM_MAX_VCPUS; > break; > + case KVM_CAP_MAX_VCPU_ID: > + r = KVM_MAX_VCPU_ID; > + break; > case KVM_CAP_MSI_DEVID: > if (!kvm) > r = -EINVAL; > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index f0d13d9d125d..c09259dd6286 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > case KVM_CAP_MULTI_ADDRESS_SPACE: > return KVM_ADDRESS_SPACE_NUM; > #endif > - case KVM_CAP_MAX_VCPU_ID: > - return KVM_MAX_VCPU_ID; > case KVM_CAP_NR_MEMSLOTS: > return KVM_USER_MEM_SLOTS; > default: >
On Tue, 28 May 2019 13:00:30 +0200 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > Paolo, Radim, > > would you consider this patch (or the full series) as 5.2 material or 5.3 material? FWIW, I'd consider this patch 5.2 material, as we're currently relaying wrong values to userspace. > > > On 23.05.19 18:43, Thomas Huth wrote: > > KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all > > architectures. However, on s390x, the amount of usable CPUs is determined > > during runtime - it is depending on the features of the machine the code > > is running on. Since we are using the vcpu_id as an index into the SCA > > structures that are defined by the hardware (see e.g. the sca_add_vcpu() > > function), it is not only the amount of CPUs that is limited by the hard- > > ware, but also the range of IDs that we can use. > > Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. > > So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common > > code into the architecture specific code, and on s390x we have to return > > the same value here as for KVM_CAP_MAX_VCPUS. > > This problem has been discovered with the kvm_create_max_vcpus selftest. > > With this change applied, the selftest now passes on s390x, too. > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > --- > > arch/mips/kvm/mips.c | 3 +++ > > arch/powerpc/kvm/powerpc.c | 3 +++ > > arch/s390/kvm/kvm-s390.c | 1 + > > arch/x86/kvm/x86.c | 3 +++ > > virt/kvm/arm/arm.c | 3 +++ > > virt/kvm/kvm_main.c | 2 -- > > 6 files changed, 13 insertions(+), 2 deletions(-)
On 28.05.19 14:53, Cornelia Huck wrote: > On Tue, 28 May 2019 13:00:30 +0200 > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > >> Paolo, Radim, >> >> would you consider this patch (or the full series) as 5.2 material or 5.3 material? > > FWIW, I'd consider this patch 5.2 material, as we're currently relaying > wrong values to userspace. Agreed. I will add cc stable and queue for master. What is our opinion about kselftest? Are we merging testtools changes also only during the merge window? > >> >> >> On 23.05.19 18:43, Thomas Huth wrote: >>> KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all >>> architectures. However, on s390x, the amount of usable CPUs is determined >>> during runtime - it is depending on the features of the machine the code >>> is running on. Since we are using the vcpu_id as an index into the SCA >>> structures that are defined by the hardware (see e.g. the sca_add_vcpu() >>> function), it is not only the amount of CPUs that is limited by the hard- >>> ware, but also the range of IDs that we can use. >>> Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. >>> So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common >>> code into the architecture specific code, and on s390x we have to return >>> the same value here as for KVM_CAP_MAX_VCPUS. >>> This problem has been discovered with the kvm_create_max_vcpus selftest. >>> With this change applied, the selftest now passes on s390x, too. >>> >>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> --- >>> arch/mips/kvm/mips.c | 3 +++ >>> arch/powerpc/kvm/powerpc.c | 3 +++ >>> arch/s390/kvm/kvm-s390.c | 1 + >>> arch/x86/kvm/x86.c | 3 +++ >>> virt/kvm/arm/arm.c | 3 +++ >>> virt/kvm/kvm_main.c | 2 -- >>> 6 files changed, 13 insertions(+), 2 deletions(-) >
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 6d0517ac18e5..0369f26ab96d 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -1122,6 +1122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; break; + case KVM_CAP_MAX_VCPU_ID: + r = KVM_MAX_VCPU_ID; + break; case KVM_CAP_MIPS_FPU: /* We don't handle systems with inconsistent cpu_has_fpu */ r = !!raw_cpu_has_fpu; diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 3393b166817a..aa3a678711be 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -657,6 +657,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; break; + case KVM_CAP_MAX_VCPU_ID: + r = KVM_MAX_VCPU_ID; + break; #ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO: r = 1; diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index 8d6d75db8de6..871d2e99b156 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -539,6 +539,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_NR_VCPUS: case KVM_CAP_MAX_VCPUS: + case KVM_CAP_MAX_VCPU_ID: r = KVM_S390_BSCA_CPU_SLOTS; if (!kvm_s390_use_sca_entries()) r = KVM_MAX_VCPUS; diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 536b78c4af6e..09a07d6a154e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3122,6 +3122,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; break; + case KVM_CAP_MAX_VCPU_ID: + r = KVM_MAX_VCPU_ID; + break; case KVM_CAP_PV_MMU: /* obsolete */ r = 0; break; diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 90cedebaeb94..7eeebe5e9da2 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -224,6 +224,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; break; + case KVM_CAP_MAX_VCPU_ID: + r = KVM_MAX_VCPU_ID; + break; case KVM_CAP_MSI_DEVID: if (!kvm) r = -EINVAL; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f0d13d9d125d..c09259dd6286 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3146,8 +3146,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) case KVM_CAP_MULTI_ADDRESS_SPACE: return KVM_ADDRESS_SPACE_NUM; #endif - case KVM_CAP_MAX_VCPU_ID: - return KVM_MAX_VCPU_ID; case KVM_CAP_NR_MEMSLOTS: return KVM_USER_MEM_SLOTS; default:
KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using the vcpu_id as an index into the SCA structures that are defined by the hardware (see e.g. the sca_add_vcpu() function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use. Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as for KVM_CAP_MAX_VCPUS. This problem has been discovered with the kvm_create_max_vcpus selftest. With this change applied, the selftest now passes on s390x, too. Signed-off-by: Thomas Huth <thuth@redhat.com> --- arch/mips/kvm/mips.c | 3 +++ arch/powerpc/kvm/powerpc.c | 3 +++ arch/s390/kvm/kvm-s390.c | 1 + arch/x86/kvm/x86.c | 3 +++ virt/kvm/arm/arm.c | 3 +++ virt/kvm/kvm_main.c | 2 -- 6 files changed, 13 insertions(+), 2 deletions(-)