Re: [PATCH] KVM: VMX: Postpone IPIv setup after successful vCPU creation

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 20, 2026, Kai Huang wrote:
> > E.g. for the xarray approacy (sketch only, completely untested):
> > 
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index fdbd697d0337..e34ca5920393 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -791,6 +791,7 @@ struct kvm {
> >         /* The current active memslot set for each address space */
> >         struct kvm_memslots __rcu *memslots[KVM_MAX_NR_ADDRESS_SPACES];
> >         struct xarray vcpu_array;
> > +       struct xarray pending_vcpu_ids;
> >         /*
> >          * Protected by slots_lock, but can be read outside if an
> >          * incorrect answer is acceptable.
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 2df8ee9ecf6c..8bc4f7ffd76d 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -4179,6 +4179,12 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, unsigned long id)
> >                 return r;
> >         }
> >  
> > +       r = xa_insert(&kvm->pending_vcpu_ids, id, xa_mk_value(id), GFP_KERNEL);
> > +       if (r) {
> > +               mutex_unlock(&kvm->lock);
> > +               return r;
> > +       }
> > +
> 
> (No preference between xarray vs bitmap)
> 
> Should we move this before kvm_arch_vcpu_precreate() to avoid any "precreate"
> for duplicated vcpu_id?

Hmm, I'm not sure.  I'm leaning "yes".  At a glance, I like the idea.  My only
concern is that we could consume a garbage @id if kvm_arch_vcpu_precreate()
performs additional checks on @id, as x86's implementation does.  However, I
don't think that's a meaningful concern since kvm_vm_ioctl_create_vcpu() *must*
perform at least basic sanity checks.

So yeah, I think moving the check before precreate() makes sense.