Re: [PATCH v3 RESEND 04/10] KVM: PPC: selftests: powerpc enable kvm_create_max_vcpus test

[Sean Christopherson <seanjc@google.com>]

On Fri, Jun 12, 2026, Ritesh Harjani wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > On Wed, Jun 10, 2026, Ritesh Harjani (IBM) wrote:
> >> From: Nicholas Piggin <npiggin@gmail.com>
> >> 
> >> powerpc's maximum permitted vCPU ID depends on the VM's SMT mode, and
> >> the maximum reported by KVM_CAP_MAX_VCPU_ID exceeds a simple non-SMT
> >> VM's limit.
> >> 
> >> The powerpc KVM selftest port uses non-SMT VMs, so add a workaround
> >> to the kvm_create_max_vcpus test case to limit vCPU IDs to
> >> KVM_CAP_MAX_VCPUS on powerpc.
> >
> > How is this not a KVM bug?  Literally the reason this test exists is to validate
> > KVM's advertised KVM_CAP_MAX_VCPU_ID and KVM_CAP_MAX_VCPUS.
> 
> It's not a KVM bug, it's expected on PowerPC. On PowerPC, vCPU ID encodes SMT topology, e.g. on P9,
> vcpu id = core * stride + thread,
>   .. where the stride is same as kvm->arch.emul_smt_mode (VM's emulated SMT mode)
> 
> So the vcpu ID space can be sparse, however KVM_CAP_MAX_VCPU_ID is the
> absolute ceil value (MAX_SMT_THREADS * KVM_MAX_VCORES) i.e. the value
> with the maximum stride / SMT value.
> 
> Since default selftest VM uses stride 1, so it rejects IDS >= max_vcpus.
> 
> e.g.
> static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu *vcpu)
> ...
> 		if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
> 			pr_devel("KVM: VCPU ID too high\n");
> 			core = KVM_MAX_VCORES;              /* rejected case */
> 		} else {
> 
> So, it's expected on PowerPC. vcpus with higher IDs can be created but
> for that we need to set KVM_CAP_PPC_SMT and use strided (sparse) IDs.
> But since the test as of now is not doing that - that's the reason why
> the patch only allows to test max vcpu IDs upto max vcpus.
> 
> But I guess you must be hating the #ifdef __powerpc__ there. I agree I
> don't like it either.. maybe we can do it this way?

I don't love the #ifdef, but it's more that I didn't want to effectively skip a
test because KVM was reporting bad information.  But after peeking at KVM_CAP_PPC_SMT,
I 100% agree we don't want to deal with that here.

> -#ifdef __powerpc64__
>         /*
> -        * powerpc has a particular format for the vcpu ID that depends on
> -        * the guest SMT mode, and the max ID cap is too large for non-SMT
> -        * modes, where the maximum ID is the same as the maximum vCPUs.
> +        * Some architectures (e.g. powerpc) encode topology into the vCPU ID,
> +        * so a default VM can't necessarily use the full advertised ID range.
> +        * Let the arch limit the highest ID this test will create.
>          */
> -       kvm_max_vcpu_id = kvm_max_vcpus;
> -#endif
> +       kvm_max_vcpu_id = kvm_arch_vcpu_id_limit(kvm_max_vcpus, kvm_max_vcpu_id);
> 
> 
> And then in kvm_util.c -
> +
> +__weak int kvm_arch_vcpu_id_limit(int nr_vcpus, int vcpu_id_max)
> +{
> +       return vcpu_id_max;
> +}

What if we do this?  We're going to be bleeding PPC details into the test no
matter what, adding an arch hooks just seems like extra cruft and an unnecessary
layer of indirection.

	/*
	 * Skip the vCPU ID test when running on PowerPC with SMT support, in
	 * which case system topology is encoded into the vCPU ID, and so a VM
	 * can't use the full advertised vCPU ID range without crafting a valid
	 * platform specific topology.
	 */
	if (kvm_max_vcpu_id > kvm_max_vcpus && !kvm_check_cap(KVM_CAP_PPC_SMT))
		test_vcpu_creation(
			kvm_max_vcpu_id - kvm_max_vcpus, kvm_max_vcpus);