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

[Sean Christopherson]

On Thu, Jul 23, 2026, Jim Mattson wrote:
> 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, 

Way off topic, I keep reading NASID as NSAID and can't help but wonder if you've
found another way to imply that KVM is diseased and needs drugs ;-)

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

+1000