On Tue, 2024-07-09 at 11:30 -0700, Sean Christopherson wrote: > 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. Looking from this POV, it make sense. > > 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. > Let it be then, Best regards, Maxim Levitsky