[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/5] x86/monitor: Capture Xen's intent to use monitor at boot time
>>> On 12.01.18 at 19:37, <andrew.cooper3@xxxxxxxxxx> wrote: > @@ -312,6 +313,12 @@ static void generic_identify(struct cpuinfo_x86 *c) > if ( cpu_has(c, X86_FEATURE_CLFLUSH) ) > c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; > > + /* Xen only uses MONITOR if INTERRUPT_BREAK is available. */ > + if ( cpu_has(c, X86_FEATURE_MONITOR) && > + ((cpuid_ecx(CPUID_MWAIT_LEAF) & CPUID_MWAIT_MIN_FEATURES) == > + CPUID_MWAIT_MIN_FEATURES) ) > + set_bit(X86_FEATURE_XEN_MONITOR, c->x86_capability); Leaving aside that this could/should be __set_bit(), I think we shouldn't do anything like this for synthetic feature bits and at the same time ... > @@ -104,6 +100,7 @@ > #define cpu_has_arch_perfmon boot_cpu_has(X86_FEATURE_ARCH_PERFMON) > #define cpu_has_cpuid_faulting boot_cpu_has(X86_FEATURE_CPUID_FAULTING) > #define cpu_has_aperfmperf boot_cpu_has(X86_FEATURE_APERFMPERF) > +#define cpu_has_xen_monitor boot_cpu_has(X86_FEATURE_XEN_MONITOR) ... test for them like this. Either we're certain all CPUs are identical, in which case the above should be setup_force_cpu_cap(), or each CPU should really inspect its own feature flag before using the feature. I'd got the former route for now, and with that change Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |