Re: [PATCH 11/11] x86/cpu: Make all all CPUID leaf names consistent

[Sean Christopherson <seanjc@google.com>]

On Mon, Dec 09, 2024, Dave Hansen wrote:
> On 12/9/24 08:27, Sean Christopherson wrote:
> > As for "cap_nr", IMO that is a net negative relative to "leaf".  For all CPUID
> > leaves that KVM cares about, the array entry is guaranteed to correspond to a
> > single CPUID leaf, albeit for only one output register.  KVM has definitely
> > bastardized "leaf", but I do think it helps convey that the "word" being modified
> > corresponds 1:1 with a specific CPUID leaf output.
> 
> I'm having a little trouble parsing this.

Gah, sorry, too much implied KVM knowledge.

> I think you're saying that, right now, if KVM cares about a CPUID leaf
> that it only cares about a single _word_, even if the core x86 code
> cares about multiple words. So the concept of a word is actually mostly
> changeable with a leaf ... for now.
> 
> Is that right?

No.  What I was trying to say is that KVM's CPUID code only ever manipulates
words that are hardware-defined, i.e. that aren't any of the CPUID_LNX_x words.

Because KVM doesn't care about the Linux-defined words, "leaf" can be used to
refer to a specific CPUID leaf+register without being too misleading, i.e. doesn't
incorrectly suggest that the Linux-defined words somehow correspond to CPUID
leaves.  KVM usage of "leaf" isn't perfectly aligned with the SDM's usage, but
I can't recall anyone ever complaining that KVM's usage of "leaf" is confusing.

On the plus side, "leaf" helps communicate to readers that the code is dealing
with the data, as opposed to referring to the function+index values themselves.
And IMO, "leaf" is much more self-documenting that "word" or "cap_nr".