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

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 22, 2026, Yosry Ahmed wrote:
> On Wed, Jul 22, 2026 at 3:26 PM Sean Christopherson <seanjc@google.com> 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?

Purely because I wrote that suggestion when looking at that final code in this
series that passed "VMX_NR_VPIDS - 1" as @nr, and didn't think too hard about the
math.

> Is it to avoid allocating an extra long just for one 1 bit?

FWIW, it's not actually an extra long, __KERNEL_DIV_ROUND_UP(0xffff, 64) and
__KERNEL_DIV_ROUND_UP(0x10000, 64) both come out as 1024.

> 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?

The VMX code should use VMX_NR_VPIDS, that's its architectural max.  I say avoid
a #define and keep the limit internal to kvm_init_tlb_tags().  I can't think of
any reason to expose that limit outside of the allocation.  E.g.

int kvm_init_tlb_tags(unsigned int nr, unsigned int nr_reserved)
{
	/*
	 * Limit the number of TLB tags to VMX's hardcoded maximum of 0x10000
	 * to avoid wasting memory for the bitmap in the unlikely scenario the
	 * CPU supports an inordinate number of ASIDs (on AMD).  If userspace
	 * wants to concurrently run tens of thousands of vCPUs, they'll likely
	 * need a solution that works for both Intel and AMD.
	 */
	const unsigned int MAX_NR_TLB_TAGS = VMX_NR_VPIDS;

> > 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.