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

[Sean Christopherson]

On Wed, Jul 22, 2026, Jim Mattson wrote:
> On Wed, Jul 22, 2026 at 3:09 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >
> > On Tue, Jul 14, 2026, Jim Mattson 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.
> >
> > 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.
> 
> That's not the only conceivable implementation.

But it is what is proposed in this series.

> KVM could advertise 64 ASIDs to L1 and reserve the corresponding non-zero
> ASIDs for L2 VMs (i.e. the first L1 ASID is 64). Then, vmcb02.asid =
> vmcb12.asid & 0x3f.
> 
> > 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.
> 
> But you could refuse a userspace CPUID model that claims more ASIDs
> than KVM supports.

Nah, that's not the KVM way.  For this one in particular, there's zero reason to
enforce anything.  Practically speaking, *if* we want KVM to act like hardware
and ignore unsupported ASIDs, then KVM *must* allow userspace to define a max ASID
other than exactly what's reported by KVM_GET_SUPPORTED_CPUID, otherwise migration
pools become impossible.  And at that point, disallowing a larger max ASID adds
zero value.

If KVM claiming support for an explicit number of ASIDs is a sticking point, then
I vote to zero the output in KVM_GET_SUPPORTED_CPUID, but I'd prefer not to do
that because it will break reflecting KVM_GET_SUPPORTED_CPUID directly back into
KVM_SET_CPUID2.

> And __nested_copy_vmcb_control_to_cache() already ignores a bunch of
> unsupported bits. I don't see how this is any different. That's how
> the hardware is implemented. Intel likes to fail VM-entry. AMD prefers
> to just ignore hypervisor stupidity and move on.

The issue is that KVM has played nice with unsupported ASIDs for years.  If we
want to change that, it needs to be quirked.  And I just don't see the point,
because KVM's behavior isn't outright wrong: the APM doesn't say what will happen
if the hypervisor is being stupid.