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

[Sean Christopherson]

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