From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching Date: Fri, 22 Jan 2016 10:05:27 +0000 Message-ID: <56A1FEE7.9060905@citrix.com> References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com> <1450301073-28191-26-git-send-email-andrew.cooper3@citrix.com> <56A1FCC902000078000C9E80@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A1FCC902000078000C9E80@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 22/01/16 08:56, Jan Beulich wrote: >>>> On 16.12.15 at 22:24, 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