[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching
>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> 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.) > --- 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |