| Message ID | 20210412222656.3466987-3-farosas@linux.ibm.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
| Series | kvm selftests and MAX_VCPU_ID | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (d02429becbe77bc4d27a7357afaf28f9294945bb) |
| snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
| snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 11 lines checked |
| snowpatch_ozlabs/needsstable | success | Patch has no Fixes tags |
Le 13/04/2021 à 00:26, Fabiano Rosas a écrit : > The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6 > ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than > KVM_MAX_VCPU in powerpc. > > For a P9 host we depend on the guest VSMT value to know what is the > maximum number of vcpu id we can support: > > kvmppc_core_vcpu_create_hv: > (...) > if (cpu_has_feature(CPU_FTR_ARCH_300)) { > --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) { > pr_devel("KVM: VCPU ID too high\n"); > core = KVM_MAX_VCORES; > } else { > BUG_ON(kvm->arch.smt_mode != 1); > core = kvmppc_pack_vcpu_id(kvm, id); > } > } else { > core = id / kvm->arch.smt_mode; > } > > which means that the value being returned by the capability today for > a given guest is potentially way larger than what we actually support: > > \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES) > > If the capability is queried before userspace enables the > KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated > smt mode is already known we could provide a more accurate value. > > The only practical effect of this change today is to make the > kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has > a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not > reached. > > Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> This patch won't apply after commit a1c42ddedf35 ("kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS") Feel free to resubmit if still applicable. Christsophe > > --- > I see that for ppc, QEMU uses the capability after enabling > KVM_CAP_PPC_SMT, so we could change QEMU to issue the check extension > on the vm fd so that it would get the more accurate value. > --- > arch/powerpc/kvm/powerpc.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > index a2a68a958fa0..95c9f47cc1b3 100644 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@ -649,7 +649,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > r = KVM_MAX_VCPUS; > break; > case KVM_CAP_MAX_VCPU_ID: > - r = KVM_MAX_VCPU_ID; > + if (hv_enabled && cpu_has_feature(CPU_FTR_ARCH_300)) > + r = KVM_MAX_VCPUS * ((kvm) ? kvm->arch.emul_smt_mode : 1); > + else > + r = KVM_MAX_VCPU_ID; > break; > #ifdef CONFIG_PPC_BOOK3S_64 > case KVM_CAP_PPC_GET_SMMU_INFO:
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Le 13/04/2021 à 00:26, Fabiano Rosas a écrit : >> The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6 >> ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than >> KVM_MAX_VCPU in powerpc. >> >> For a P9 host we depend on the guest VSMT value to know what is the >> maximum number of vcpu id we can support: >> >> kvmppc_core_vcpu_create_hv: >> (...) >> if (cpu_has_feature(CPU_FTR_ARCH_300)) { >> --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) { >> pr_devel("KVM: VCPU ID too high\n"); >> core = KVM_MAX_VCORES; >> } else { >> BUG_ON(kvm->arch.smt_mode != 1); >> core = kvmppc_pack_vcpu_id(kvm, id); >> } >> } else { >> core = id / kvm->arch.smt_mode; >> } >> >> which means that the value being returned by the capability today for >> a given guest is potentially way larger than what we actually support: >> >> \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES) >> >> If the capability is queried before userspace enables the >> KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated >> smt mode is already known we could provide a more accurate value. >> >> The only practical effect of this change today is to make the >> kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has >> a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not >> reached. >> >> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> > > This patch won't apply after commit a1c42ddedf35 ("kvm: rename > KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS") > > Feel free to resubmit if still applicable. Thanks for the reminder, Christophe. I was focusing on enabling the rest of the kvm-selftests: https://lore.kernel.org/r/20220120170109.948681-1-farosas@linux.ibm.com I'm preparing a v2 for that series and will try to include these patches as well.
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index a2a68a958fa0..95c9f47cc1b3 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -649,7 +649,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) r = KVM_MAX_VCPUS; break; case KVM_CAP_MAX_VCPU_ID: - r = KVM_MAX_VCPU_ID; + if (hv_enabled && cpu_has_feature(CPU_FTR_ARCH_300)) + r = KVM_MAX_VCPUS * ((kvm) ? kvm->arch.emul_smt_mode : 1); + else + r = KVM_MAX_VCPU_ID; break; #ifdef CONFIG_PPC_BOOK3S_64 case KVM_CAP_PPC_GET_SMMU_INFO:
The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6 ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than KVM_MAX_VCPU in powerpc. For a P9 host we depend on the guest VSMT value to know what is the maximum number of vcpu id we can support: kvmppc_core_vcpu_create_hv: (...) if (cpu_has_feature(CPU_FTR_ARCH_300)) { --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) { pr_devel("KVM: VCPU ID too high\n"); core = KVM_MAX_VCORES; } else { BUG_ON(kvm->arch.smt_mode != 1); core = kvmppc_pack_vcpu_id(kvm, id); } } else { core = id / kvm->arch.smt_mode; } which means that the value being returned by the capability today for a given guest is potentially way larger than what we actually support: \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES) If the capability is queried before userspace enables the KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated smt mode is already known we could provide a more accurate value. The only practical effect of this change today is to make the kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not reached. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> --- I see that for ppc, QEMU uses the capability after enabling KVM_CAP_PPC_SMT, so we could change QEMU to issue the check extension on the vm fd so that it would get the more accurate value. --- arch/powerpc/kvm/powerpc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)