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

[Yosry Ahmed]

On Tue, Jul 14, 2026 at 4:41 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Tue, Jul 14, 2026, Yosry Ahmed wrote:
> > On Tue, Jul 14, 2026 at 2:28 PM Jim Mattson <jmattson@xxxxxxxxxx> 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.

Right, but KVM could decide to start doing that in the future and
still be architecturally sound.

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

See below.

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

Right, for the CPU, but why would it be suboptimal for KVM to
advertise the max number of ASIDs. It's actually more optimal with the
current implementation of KVM, because L1 KVM has the least chance of
doing a full flush and flushing its own TLB entries unnecessarily.

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

I agree, but nothing guarantees that, unless it falls under "don't
break userspace"?

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

Yeah, like this patch essentially.

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

I think the ASIDs case is more nuanced, at least in my mind, because:
- It's more likely for future CPUs to advertise a lower number of
ASIDs than stop supporting a feature.
- What KVM advertises to userspace is not really a hard cap, it's
actually meaningless today, and userspace can just ignore it and
advertise whatever and it would work. But, there is no guarantee this
will continue to work if KVM decides otherwise.

Sure, KVM can still punt this to userspace, but it might just make
VMM's lives more difficult for no good reason. This came up internally
when we discussed what our internal VMM should advertise. If we just
advertise the same number of ASIDs advertised by HW for the virtual
CPU, we risk not being able to add future AMD CPUs to the migration
pool if they have a lower number of ASIDs.

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

As long as it's "a hint" it should be fine. The problem happens if KVM
decides to make it a hard limit and ignore upper bits based on it.
AFAICT, nothing prevents KVM from doing this in the future.