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

[Jim Mattson]

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

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.