Re: [GIT PULL] KVM: Generic changes for 6.20

[Sean Christopherson <seanjc@google.com>]

On Mon, Feb 09, 2026, Sean Christopherson wrote:
> On Mon, Feb 09, 2026, Paolo Bonzini wrote:
> > On Mon, Feb 9, 2026 at 6:38 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
> > >
> > > On Sat, Feb 7, 2026 at 5:10 AM Sean Christopherson <seanjc@google.com> wrote:
> > > >  - Document that vcpu->mutex is take outside of kvm->slots_lock, which is all
> > > >    kinds of unintuitive, but is unfortunately the existing behavior for
> > > >    multiple architectures, and in a weird way actually makes sense.
> > >
> > > I disagree that it is "arguably wrong" how you put it in the commit
> > > message. vcpu->mutex is really a "don't worry about multiple ioctls at
> > > the same time" mutex that tries to stay out of the way.  It only
> > > becomes unintuitive in special cases like
> > > tdx_acquire_vm_state_locks().
> > >
> > > By itself this would not be a reason to resend, but while at it you
> > > could mention that vcpu->mutex is taken outside kvm->slots_arch_lock?
> > 
> > ... as well as mention kvm_alloc_apic_access_page() in the commit message.
> 
> Ya, will do.

Finally got around to prepping a v2, and I realized that vcpu->mutex isn't held
when kvm_alloc_apic_access_page() is called, and thus isn't (currently) taken
outside kvm->slots_arch_lock.

avic_init_backing_page() and kvm_alloc_apic_access_page() are called with a vCPU,
but only via kvm_arch_vcpu_create(), when neither vcpu->mutex nor kvm->lock are
held (the vCPU is still unreachable).

Given that locking.rst doesn't bother documenting that kvm->lock is taken outside
kvm->slots_arch_lock (there's a whole section on slots locking), I'm inclined to
keep the new entry as just:

  - vcpu->mutex is taken outside kvm->slots_lock

But update the changelog to not claim that the behavior is "arguablyh wrong".