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

[Sean Christopherson <seanjc@google.com>]

On Sat, Feb 28, 2026, Paolo Bonzini wrote:
> On Sat, Feb 28, 2026 at 12:21 AM Sean Christopherson <seanjc@google.com> wrote:
> > 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.
> 
> It is, via kvm_mmu_new_pgd (kvm_mmu_reload -> kvm_mmu_load ->
> mmu_alloc_shadow_roots -> mmu_first_shadow_root_alloc).  In fact
> commit b10a038e added slots_arch_lock exactly to have something that
> could be taken within the SRCU critical section, and thus within
> vcpu->mutex :)

Oh, right, duh.  I was fixated on kvm_alloc_apic_access_page() and didn't think
about the "other" side of the lock (i.e. the whole reason the lock exists...).

Oof, and it's also taken via

  kvm_inhibit_apic_access_page()
  |
  -> __x86_set_memory_region()
     |
     -> kvm_set_internal_memslot()
        |
        -> kvm_set_memory_region()
           |
           -> kvm_set_memslot()

So I was right about kvm_alloc_apic_access_page(), and wrong about everything
else.  Go me.

> (slots_arch_lock is also taken inside slots_lock, and therefore it
> must be taken inside vcpu->mutex transitively; but more to the point
> it exists specifically to be taken during KVM_RUN).