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

[Yosry Ahmed]

On Thu, Jul 23, 2026 at 8:57 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Thu, Jul 23, 2026 at 7:07 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >
> > On Thu, Jul 23, 2026, Jim Mattson wrote:
> > > 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.
> >
> > Or keep KVM's enumeration at 8, then find somewhere in KVM's documentation to
> > describe KVM's behavior and provide guidance for userspace, but otherwise make
> > it userspace's problem to solve?  I'd be a-ok with that.
>
> That sounds best to me. Document that KVM ignores the guest NASID and
> commits to always supporting 2^32 ASIDs. Advise userspace to populate
> NASID with a power of 2, and perhaps mention that hardware has only
> reported three different values over the last 20 years: 0x40, 0x10000,
> and 0x8000.

I agree that documenting that KVM supports any NASID value from
userspace is needed here, so that VMMs can set reasonable values and
migration pools are sane.

That being said, I still think KVM's enumeration should be increased
from 8. If KVM's enumeration is just a hint, then it should be a good
one imo. Current L1 KVM will flush everything (L1 + L2) every time it
runs out of ASIDs and pumps the generation, so advertising a small
number of ASIDs leads to L1 unnecessarily hurting its performance.
Newer KVM (with this series) won't suffer as much.

I think we probably want to pump KVM enumeration (e.g. to 0x8000 or
even 0x40) *and* document that it's just a hint and KVM effectively
allows any value.