On 25/02/2019 17:01, Jan Beulich wrote: >>>> On 25.02.19 at 16:03, <andrew.coop...@citrix.com> wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -414,6 +414,10 @@ static void generic_identify(struct cpuinfo_x86 *c) >> >> &c->x86_capability[cpufeat_word(X86_FEATURE_FSGSBASE)], >> &c->x86_capability[cpufeat_word(X86_FEATURE_PKU)], >> >> &c->x86_capability[cpufeat_word(X86_FEATURE_AVX512_4VNNIW)]); >> + if ( c->cpuid_level >= 0xd ) >> + cpuid_count(0xd, 1, >> + >> &c->x86_capability[cpufeat_word(X86_FEATURE_XSAVEOPT)], >> + &tmp, &tmp, &tmp); > I think this file is still trying to be Linux style, with a couple of > violations. I do notice that the immediately preceding if() is > the same style as the one you add, but I think it would be > more consistent to omit the blanks immediately inside the > parentheses here.
/sigh - will fix. > Either way, > Acked-by: Jan Beulich <jbeul...@suse.com> > > I take it that you're intentionally using 0xd in favor of > XSTATE_CPUID? XSTATE_CPUID is a bit of an oddity. CPUID leaves are much more commonly referred to in their numeric form, both in the documentation and in technical discussion. A specific bonus of using 0xd here is that you can trivially confirm that it is checked against the correct cpuid_level. > As an aside I wonder why we have cpuid_count_ebx(), but > not e.g. cpuid_count_eax() as would have been useful here. Pass. I don't find those helpers terribly helpful, because they almost always lead (over time) to redundant invocations of CPUID. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
