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

[Sean Christopherson <seanjc@google.com>]

On Wed, Oct 14, 2026, Yosry Ahmed wrote:
> On Wed, Oct 14, 2026 at 6:23 AM Jim Mattson <jmattson@google.com> wrote:
> >
> > On Mon, Oct 12, 2026 at 4:36 PM Yosry Ahmed <yosry@kernel.org> 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@linux.dev/
> 
> 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@kernel.org/
> 
> 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.

+1.  The per-pCPU tracking might require less code, but OMG is it hard to reason
about.  I also hate having completely different schemes for VMX vs. SVM, it makes
it extra difficult to reason about TLB stuff when looking at KVM x86 as a whole.

The other big argument for per-vCPU ASIDs is that it will allow us to elide TLB
flushes on task migration[*], which might not be a major performance win for bare
metal, but it can be a significant win when running nested.

https://lore.kernel.org/all/aHWjPSIdp5B-2UBl@google.com