Re: [RFC PATCH v2 03/25] KVM: VMX: Generalize VPID allocation to be vendor-neutral

[Yosry Ahmed]

On Wed, Jul 22, 2026 at 3:26 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Tue, Jun 16, 2026, Yosry Ahmed wrote:
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 9368a71336fe4..e021ed562502f 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -8192,4 +8192,68 @@ void kvm_mmu_init_memslot_memory_attributes(struct kvm *kvm,
> >               }
> >       }
> >  }
> > +
> > +static struct {
> > +     spinlock_t      lock;
> > +     unsigned long   *bitmap;
> > +     unsigned int    nr;
> > +} tlb_tags;
> > +
> > +int kvm_init_tlb_tags(unsigned int nr)
> > +{
> > +     if (WARN_ON_ONCE(!nr))
>
> I think we should cap @nr at 0xffff, i.e. at VMX_NR_VPIDS -1.  If we end up on

Why not VMX_NR_VPIDS (i.e. 0x10000) like the current implementation?
Is it to avoid allocating an extra long just for one 1 bit? It would
be a change of behavior for VMX tho, not that anyone would care.

If we do this, I'd rather replace VMX_NR_VPIDS with a generic
MAX_NR_TLB_TAGS, and just have the VMX code use that. WDYT?

> a system (e.g. in a VM) that supports 4 billion ASIDs, KVM will burn 64MiB for
> the bitmap, without any reasonable hope of actually consuming anywhere near that
> many ASIDs.  Burning at most 1024 bytes is far more reasonable.
>
> To provide some defence against future systems, maybe pr_warn() or something if
> the number of ASIDs is capped?

Sounds good.