Re: [RFC PATCH v2 02/25] KVM: SVM: Passthrough the number of supported ASIDs
From: Jim Mattson
Date: Thu Jul 23 2026 - 13:06:44 EST
On Thu, Jul 23, 2026 at 9:32 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> 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.
How do you do that without breaking rollback?