Re: [RFC PATCH v2 02/25] KVM: SVM: Passthrough the number of supported ASIDs

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 14, 2026, Jim Mattson wrote:
> On Tue, Jul 14, 2026 at 4:41 PM Sean Christopherson <seanjc@google.com> 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.

But that doesn't have anything to do with the number of ASIDs that KVM enumerates
to L1.  As of this series, the number ASIDs KVM will consume in hardware is a
property of the total number of vCPUs in the system (one ASID per vCPU, plus one
more for nested usage).  E.g. if KVM advertises 10000 ASIDs to L1, all 10000
(10001, if ASID=0 counts?) of the those ASIDs will map to svm->nested.asid02.

Of course, that completely undermines my statement about suboptimal performance:

  And potentially suboptimal for performance.  There might be a legitimate reason
  why a CPU generation advertises X instead of Y.

My bogus assertion about performance notwithstanding, I still think advertising
what hardware supports is the simple, sane approach.  Because at the end of the
day it's just that: advertising.  Userspace can do whatever it wants, including
peeking at raw CPUID.  E.g. if we want to pull a stupid and emulate the behavior
of ignoring "unsupported" ASIDs, then we'd need to do that based on userspace's
defined CPUID model, not KVM's advertised support.