Re: [PATCH v3 00/27] KVM: nSVM: Optimize nSVM TLB flushes

[Yosry Ahmed]

On Wed, Oct 14, 2026 at 6:23 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2026 at 4:36 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > This series optimizes TLB flushes for nested SVM by using and maintaining
> > a separate ASID for L2 for each vCPU (similar to VMX's handling of VPIDs),
> > rather than sharing the same ASID and flushing everything on every nested
> > transition.
> >
> > The series also drops the dynamic ASID allocation scheme and uses a
> > static ASID per vCPU (or two if using nested), bringing it closer to how
> > VMX handles VPIDs. Modern CPUs (Rome, Milan, Genoa, Turin) advertise 32K
> > ASIDs, so there is no need for dynamic allocation.
>
> I'm not convinced that this is the right direction. It's almost always
> better to do things locally when possible. Why not keep the per-CPU
> generational allocation, but allocate two ASIDs per vCPU—one for each
> VMCB?

This is what a much older version of this series did:
https://lore.kernel.org/lkml/20250205182402.2147495-1-yosry.ahmed@xxxxxxxxx/

Then we moved on to per-VM fixed ASIDs to align with SEV, but the
tracking of "which vCPU used this ASID last" was annoying, so we
settled on per-vCPU fixed ASIDs, similar to VPIDs, with the caveat of
not being able to disable ASID (Hence the fallback ASID thing).

Other than alignment, dynamic allocation of ASIDs means that we need
to handle the possibility of ASID reuse, which imo introduces more
complexity than the fallback ASID logic, patch 10 lists three very
recent fixups that we need to handle corner cases with dynamic ASID
allocations:
https://lore.kernel.org/kvm/20261012233638.2546339-11-yosry@xxxxxxxxxx/

There is a 4th one that was sent after patch 10.

Also, the dynamic ASID allocations give the VMs more noisy neighbor
power, I think the ASID is reallocated on INIT, so a VM can trigger
running out of ASIDs on a pCPU and flushing the ASIDs of all other
VMs. Yes, we can handle this in INIT, but the problem is completely
side-stepped by using static ASIDs.

> This would eliminate the need for a fallback ASID and remove any
> possible concerns about contention for a global bitmap.

The fallback ASID logic is annoying, yes, but it's only in a few
places. I don't think there's a risk of real contention in most
practical use cases, we can run 32k vCPUs per pCPU before we run into
issues. I think we will hit other scalability limits before the
fallback ASID becomes a problem.

> Moreover, it would be much simpler to implement.

The delta is smaller and simpler, yes. But I think the static ASIDs
code ends up being simpler to reason about.