Re: [PATCH v2 37/49] KVM: x86: Replace guts of "governed" features with comprehensive cpu_caps

[Sean Christopherson]

On Thu, Jul 04, 2024, Maxim Levitsky wrote:
> On Fri, 2024-05-17 at 10:39 -0700, Sean Christopherson wrote:
> > @@ -861,23 +877,20 @@ struct kvm_vcpu_arch {
> >  	bool is_amd_compatible;
> >  
> >  	/*
> > -	 * FIXME: Drop this macro and use KVM_NR_GOVERNED_FEATURES directly
> > -	 * when "struct kvm_vcpu_arch" is no longer defined in an
> > -	 * arch/x86/include/asm header.  The max is mostly arbitrary, i.e.
> > -	 * can be increased as necessary.
> > +	 * cpu_caps holds the effective guest capabilities, i.e. the features
> > +	 * the vCPU is allowed to use.  Typically, but not always, features can
> > +	 * be used by the guest if and only if both KVM and userspace want to
> > +	 * expose the feature to the guest.
> 
> Nitpick: Since even the comment mentions this, wouldn't it be better to call this
> cpu_effective_caps? or at least cpu_eff_caps, to emphasize that these are indeed
> effective capabilities, e.g these that both kvm and userspace support?

I strongly prefer cpu_caps, in part to match kvm_cpu_caps, but also because adding
"effective" to the name incorrectly suggests that there are other guest capabilities
that aren't effective.  These are the _only_ per-vCPU capabilities as far as KVM
is concerned, i.e. they are the single source of truth.  kvm_cpu_caps holds KVM's
capabilities, boot_cpu_data holds kernel capabilities, and bare metal holds its
capabilities somewhere in silicion.

E.g. being pedantic, kvm_cpu_caps are also KVM's effective capabilities, as they
are a reflection of KVM-the-module's capabilities, module params, kernel capabilities,
and CPU capabilities.