Re: [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 22/01/16 08:56, Jan Beulich wrote:
>>>> On 16.12.15 at 22:24, <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -35,6 +35,9 @@ integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
>>  unsigned int __initdata expected_levelling_cap;
>>  unsigned int __read_mostly levelling_caps;
>>  
>> +DEFINE_PER_CPU(struct cpumasks, cpumasks);
>> +struct cpumasks __read_mostly cpumask_defaults;
> Any reason these can't be introduced when first used? (The question
> really applies to the rest of this patch too, I guess.)

The subsequent two patches are sufficiently complicated in their own
right that I deliberately pulled these bits out.

>
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -585,6 +585,21 @@ int microcode_resume_cpu(unsigned int cpu);
>>   */
>>  extern unsigned int expected_levelling_cap, levelling_caps;
>>  
>> +struct cpumasks
>> +{
>> +    uint64_t _1cd;
>> +    uint64_t e1cd;
>> +    uint64_t Da1;
>> +    uint64_t _6c;
>> +    uint64_t _7ab0;
>> +};
> While I see the need for these underscore prefixes with the
> current naming scheme, perhaps it would be better to make
> this fully consistent with the acronym #define-s, by e.g.
> prefixing the base ones with 'b'? Such full naming consistency
> would allow for string concatenation in macros, should such a
> possibility ever arise, no matter whether manifest constants
> or structure members here are needed to be accessed.
>
> As to the name of the structure itself - perhaps better
> cpuidmasks?

Ok.

~Andrew