Re: [REGRESSION] KVM: x86: OVMF boot hang with SMM enabled after commit b3e6212dea2e ("KVM: x86: Use active memslots for the per-vCPU MMIO cache")

[Sean Christopherson <seanjc@google.com>]

On Wed, Oct 28, 2026, Paolo Bonzini wrote:
> On 10/28/26 18:48, Paolo Bonzini wrote:
> > On 10/28/26 18:37, Sean Christopherson wrote:
> > > > However, address space 0 and address space 1 maintain separate
> > generation counters
> > > > starting from 0.
> > 
> > This is also incorrect:
> > 
> >          for (i = 0; i < kvm_arch_nr_memslot_as_ids(kvm); i++) {
> >                  for (j = 0; j < 2; j++) {
> >                          slots = &kvm->__memslots[i][j];
> > 
> >                          atomic_long_set(&slots->last_used_slot,
> > (unsigned long)NULL);
> >                          slots->hva_tree = RB_ROOT_CACHED;
> >                          slots->gfn_tree = RB_ROOT;
> >                          hash_init(slots->id_hash);
> >                          slots->node_idx = j;
> > 
> >                          /* Generations must be different for each
> > address space. */
> >                          slots->generation = i;
> >                  }
> > 
> > 
> > > >          An MMIO access cached in SMM (e.g., GFN 0xFED40000 with
> > > > gen = 4) matches in normal mode where gen is also 4.
> > > Hmm, this isn't adding up for me.  It should be impossible for the
> > > generation to
> > > be '4' for SMM, because SMM is supposed to use odd-numbered
> > > generations.  From
> > > kvm_swap_active_memslots():
> > 
> > vcpu_cache_mmio_info() does not use the address space id:
> > 
> >          u64 gen = kvm_memslots(vcpu->kvm)->generation;
> > 
> > Will send a patch soon.
> Nevermind, wrong tree - I was reinventing the (apparently buggy) commit
> because it's past 7.3.0-rc7... still looking.

Heh, I did the same thing.  I was like, "this code doesn't exist!!!", then
realized the commit isn't in kvm/next.