Re: [RFC PATCH v2 02/25] KVM: SVM: Passthrough the number of supported ASIDs
From: Yosry Ahmed
Date: Wed Jul 15 2026 - 15:15:47 EST
On Wed, Jul 15, 2026 at 11:20 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Wed, Jul 15, 2026 at 10:45 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > On Tue, Jul 14, 2026 at 11:32 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Jul 14, 2026 at 4:41 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > >
> > > > What complications? Advertise the lowest common feature set for the pool, just
> > > > like userspace has to do for literally every other feature.
> > >
> > > The problem with passing through the number of host ASIDs to the guest
> > > is what to do when the combined host plus guest usage exceeds the
> > > number of available ASIDs, particularly when FlushByASID is not
> > > available.
> >
> > I think that particular scenario is fine because they are two separate
> > domains. KVM assigns 1 ASIDs per vCPU for L2 (in this series),
> > regardless of what L1 assigns L2. We flush that ASID if L1 changes the
> > ASID it uses. We can use more than 1 ASID in the future, but I think
> > KVM will still allocate a certain number of ASIDs per L2 and the
> > domains will remain separate.
>
> IIRC, Hyper-V uses two ASIDs per vCPU--or, at least, it used to. It
> might be worth checking to see if that is still the case.
>
> > If your concern is the fact that without FlushByASID KVM will do a lot
> > of full flushes, you are right, and this series aggressively falls
> > back to full flushes when FlushByASID isn't available, rather than
> > using a different ASID like the current approach. My assumption has
> > been that we don't care about performance that much on these old CPUs.
>
> ...until someone complains? :)
I am not sure how many people run VMs on pre-Bulldozer CPUs and care
about performance, but practically it's only a problem if the full
flush actually makes a difference. It is possible that the TLB is not
big enough; flushing the ASID vs flushing the entire TLB makes a
difference.
If we really care, it's a problem not specifically for nested, but for
assigning a fixed ASID to each vCPU in general (similar to VPIDs). It
is a nice simplification, but AFAICT it's not necessary, the very
first version of the RFC didn't have it [1], it was suggested by Sean
(well, we went to per-VM ASIDs first, then per-vCPU ASIDs).
[1]https://lore.kernel.org/lkml/20250205182402.2147495-1-yosry.ahmed@xxxxxxxxx/