On 18/07/2019 13:09, Jan Beulich wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -15,6 +15,32 @@
> #include "cpu.h"
>
> /*
> + * Processors which have self-snooping capability can handle conflicting
> + * memory type across CPUs by snooping its own cache. However, there exists
> + * CPU models in which having conflicting memory types still leads to
> + * unpredictable behavior, machine check errors, or hangs. Clear this
> + * feature to prevent its use on machines with known erratas.
> + */
> +static void __init check_memory_type_self_snoop_errata(void)
> +{
> + switch (boot_cpu_data.x86_model) {
> + case 0x0f: /* Merom */
> + case 0x16: /* Merom L */
> + case 0x17: /* Penryn */
> + case 0x1d: /* Dunnington */
> + case 0x1e: /* Nehalem */
> + case 0x1f: /* Auburndale / Havendale */
> + case 0x1a: /* Nehalem EP */
> + case 0x2e: /* Nehalem EX */
> + case 0x25: /* Westmere */
> + case 0x2c: /* Westmere EP */
> + case 0x2a: /* SandyBridge */
It would have been nice if the errata had actually been identified...
> + setup_clear_cpu_cap(X86_FEATURE_SS);
I'm regretting exposing SS to guests at this point.
As this stands, it will result in a migration compatibility issue,
because updating Xen will cause a feature to disappear. If we had a
default vs full policy split, this would be easy enough to work around
in a compatible way. I wonder if there is anything clever we can do in
the meantime as a stopgap workaround.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
