Re: [PATCH v4 1/6] x86/cpu: Use a new feature flag for 5 level paging

[Sean Christopherson <seanjc@google.com>]

On Thu, May 22, 2025, Thomas Gleixner wrote:
> On Thu, May 22 2025 at 08:08, Sean Christopherson wrote:
> > On Thu, May 22, 2025, Peter Zijlstra wrote:
> >> On Wed, May 21, 2025 at 05:23:37PM +0200, Thomas Gleixner wrote:
> >> 
> >> >    4) Drivers having access to CPUID is just wrong. We've had issues
> >> >       with that in the past because drivers evaluated CPUID themself and
> >> >       missed that the core code had stuff disabled.
> >> 
> >> I had this patch that read the module instructions and failed loading if
> >> they used 'fancy' instructions. Do you want me to revive that?
> 
> Once we have the new infrastructure in place....
> 
> > Unless you want to grant exceptions, that's not going to fly for KVM.  KVM makes
> > heavy use of CPUID, the consumption/output of which is firmly entrenched in KVM's
> > ABI.
> 
> If there is a full in memory copy of all CPUID leafs, then what needs KVM beyond
> reading it from there?

Ah, I missed that context.  If it's a truly full (e.g. includes the XSTATE sizes
sub-leafs and all that jazz) and unmodified copy, then it'll work.

If it's a modified/filtered copy, it might work?  I'd have to think/dig more.
I'm pretty sure the only CPUID-based feature that KVM supports based solely on
hardware capabilities is LA57, and it sounds like that will have special handling
anyways.

My bigger concern is cases where the kernel _adds_ features.  KVM's default
handling of features is to advertise support if and only both the host kernel
and hardware support a feature.  I.e. KVM does a bitwise-AND of CPUID and
boot_cpu_data.x86_capability.  KVM does opt-in for a handful of features, but
they are the exception, not the rule.  I don't see an obvious way to maintain
that behavior without KVM doing CPUID itself.