Re: [PATCH 3/6] x86: Define some Intel vPMU leafs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.03.2026 14:05, Teddy Astie wrote:
> Le 25/03/2026 à 12:43, Jan Beulich a écrit :
>> On 25.03.2026 10:48, Teddy Astie wrote:
>>> Le 24/03/2026 à 10:25, Jan Beulich a écrit :
>>>> On 10.03.2026 17:44, Teddy Astie wrote:
>>>>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>>>>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>>>>> @@ -162,7 +162,15 @@ struct cpu_policy
>>>>>                uint64_t :64, :64; /* Leaf 0x9 - DCA */
>>>>>    
>>>>>                /* Leaf 0xa - Intel PMU. */
>>>>> -            uint8_t pmu_version, _pmu[15];
>>>>> +            struct {
>>>>> +                uint8_t /* a */ version, num_gp_ctrs, gp_ctr_width,
>>>>> +                                event_enum_length;
>>>>> +                uint32_t /* b */:32;
>>>>> +                uint32_t /* c */ fixed_ctr_mask;
>>>>> +                uint32_t /* d */ num_fixed_ctr:5, fixed_ctr_width:8, :1,
>>>>> +                                 anythread_depreciation:1, 
>>>>> slots_per_cyc:4,
>>>>> +                                 :13;
>>>>> +            } pmu;
>>>>
>>>> Style-wise this looks to follow e.g. the cache leaf, so perhaps okay, even
>>>> if I would have preferred you to follow what we did for leaf 6.
>>>
>>> My idea was to put all that as .pmu.*, so I wouldn't need to prefix
>>> everything with "pmu_". I'm not sure if you're talking about a different
>>> approach.
>>
>> The "pmu" is fine. I'm talking of what's inside the struct {}.
>>
> 
> Is it regarding having union and _aa, _ab, (...) fields or prefixing 
> fields with pmu_ ?

As said, the "pmu" name of the containing struct is fine. Obviously then there
is no need for pmu_ prefixes. The differences between the cache leaf and leaf
6 go beyond the union aspect though, and I really mean all differences there.
As Andrew wasn't overly happy with the _6a and _6c union members, I wouldn't
insist on the introduction of counterparts here (and if they were omitted,
unions wouldn't be needed either). I think it's advisable though, allowing to
omit the trailing unnamed bitfield (the size of which you've now corrected a
2nd time).

Jan