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

[Jim Mattson]

On Thu, Jul 23, 2026 at 9:57 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Thu, Jul 23, 2026 at 9:54 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> >
> > 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?
>
> KVM's enumeration is just a hint :)

Yes, but existing userspace VMMs do not know that.

> Also, in practice, even if you rollback the CPUID presented to an
> existing VM by userspace should never change, right?

Today's KVM claims support for only 8 ASIDs. If tomorrow's KVM
supports 0x8000 ASIDS, and we start a VM on tomorrow's KVM with a
userspace that copies NASID from KVM_GET_SUPPORTED_CPUID, that VM will
look like it can't be supported on the old KVM if we have to roll
back.

Hence, until you get an ACK from *all* userspace VMMs that they
understand that KVM's reported NASID is just a hint, you can't change
the reported ASID—unless, of course, you make that change an opt-in.
But any VMM that opts in already knows that the value is just a hint,
that it can set any NASID value it wants in the guest CPUID, and that
all values are actually supported by all versions of KVM that report
any non-zero value. So, then, what's the point of the opt-in? What's
the point of changing the hint at all? Documentation solves the
problem completely.