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

[Jim Mattson]

On Wed, Jul 22, 2026 at 5:27 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> 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.

If KVM supports any userspace-provided value for NASIDS, then
shouldn't KVM_GET_SUPPORTED_CPUID return 0xffffffff?

> > 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.

The APM doesn't say that an out-of-bounds ASID causes VM-entry
failure. What other possibilities remain?