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

[Jim Mattson]

On Wed, Jul 22, 2026 at 7:46 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> 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?

Having given it some more thought, 0xffffffff might induce buggy guest behavior.

However, since KVM completely ignores NASID, it would be sad if
migration were blocked because the target has a lower NASID value than
the source.

That's an argument against changing it without some kind of userspace
opt-in. Increasing it seems safe, but if userspace just reflects the
value into KVM_SET_CPUID2, then an increase would block kernel
rollback.

In any case, I think the new value should be a constant so it doesn't
imply a migration constraint. Perhaps we should adopt the highest
value reported on a physical CPU to date? I think that would be
Bulldozer's 0x10000.

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