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

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 14, 2026, Yosry Ahmed wrote:
> On Tue, Jul 14, 2026 at 2:28 PM Jim Mattson <jmattson@google.com> wrote:
> > > > Note: QEMU currently hardcodes the number of ASIDs to 16, so this change
> > > > doesn't help QEMU VMs (without making a similar change in QEMU).
> > >
> > > I had a discussion with Jim internally about what our VMM should
> > > advertise as the number of ASIDs, and based on that I think passing
> > > through the hardware value may not be the best idea, at least not
> > > without some disclaimers.
> > >
> > > Jim pointed out that AMD CPUs will ignore unsupported ASID bits, or at
> > > least earlier ones did, even though it's not mentioned in the APM
> > > (last time I checked). This means that technically KVM can ignore the
> > > higher bits of the ASID set by L1 beyond supported ones (e.g. if it
> > > uses a hashtable to multiplex L1 ASIDs onto several physical ASIDs).
> > > KVM doesn't currently do so with or without this series, but it could.

Deliberately ignoring ASID bits would certainly be a choice.  I can see why
hardware might make that compromise, but I don't see any reason why KVM should
do the same.

> > > The problem happens if a migration pool contains multiple AMD CPUs
> > > with a different number of ASIDs in hardware. If the VMM advertises
> > > the greater value of the two, it would technically be advertising an
> > > unsupported number of ASIDs on one of the CPUs. If KVM ignores the
> > > upper bits based on what it supports, not what userspace advertises in
> > > CPUID, then userspace would be shooting itself in the foot.
> > >
> > > I think technically speaking userspace would be in the wrong for using
> > > a number of ASIDs above what KVM_GET_SUPPORTED_CPUID provides, and it
> > > should use a number of ASIDs that is supported by all CPUs in a
> > > migration pool. However, this makes the VMM's life difficult, say if
> > > AMD decides to reduce the number of ASIDs in a newer CPU just for
> > > kicks.
> > >
> > > All of this is hypothetical in nature, but it's a very valid concern imo.

Eh, I disagree.  It's hypothetical, and not a concern for KVM.

> > > I think there are several ways we can handle this so that VMMs can
> > > reasonably start advertising more ASIDs to guests without these
> > > complications:

What complications?  Advertise the lowest common feature set for the pool, just
like userspace has to do for literally every other feature.

> > > 1. We can just advertise a larger ASID value instead of 8 (say 16K or
> > > 32K), rather than passthrough what's in hardware. I assume this would
> > > mean that KVM is more-or-less committing to supporting that number of
> > > ASIDs regardless of underlying hardware (i.e. KVM wouldn't reduce it
> > > in the future). In this case, a VMM can just advertise the same value.
> > >
> > > 2. We can advertise the maximum number of ASIDs (2^32 - 1?), which is
> > > the same as option (1), except that we're biting the bullet and
> > > preventing the possibility of KVM ignoring upper bits completely.
> > > Might be too aggressive.

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

> > > 3. Document (somewhere) that KVM should use the userspace advertised
> > > value as the source of truth for ignorable bits, even if KVM
> > > technically supports a lower value. As I am writing this I am
> > > realizing it doesn't make much sense as it means that the value
> > > supported by KVM is meaningless.

As above, I don't think KVM should have "ignorable bits" in the first place.

> > > Maybe that comes naturally with the "don't break userspace" rule, but it
> > > could also fall under the category of userspace shooting itself in the
> > > foot and KVM letting it.
> > >
> > > 4. Do nothing, let this be userspace's problem, and hope that AMD
> > > doesn't reduce the number of ASIDs in a future CPU.

By "Do nothing", I assume you mean "advertise what's reported in CPUID"?

If so there's a fifth option.

 5. Be super paranoid and zero the entry, like KVM does for the topology leaves.
    See commit 45e966fcca03 ("KVM: x86: Do not return host topology information
    from KVM_GET_SUPPORTED_CPUID").
    
IMO, the only sane options are #4 and #5, and #5 feels unnecessarily paranoid.
I genuinely don't see how this is any different than any other feature where
userspace needs to not over-advertise features across its migration pool.

"Simple" use cases that don't do migration and just reflect KVM's CPUID into
the guest Just Work, and more sophisticated use cases get an explicit hint from
KVM as to the optimal number of ASIDs to advertise.  I don't see why we need to
make it more complex than that.