[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.