On 18/07/2019 14:07, Jan Beulich wrote:
> On 18.07.2019 14:23, Andrew Cooper wrote:
>> 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...
> Indeed; I hope you don't expect me to go hunt them down. I'm
> cloning a Linux commit here only, after all.
No - I don't expect you to hunt them down.
I'll try to keep an eye out next time I'm in the relevant documents.
>
>>> + 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.
> Should we perhaps introduce X86_FEATURE_XEN_SELFSNOOP, just like
> we do for SMEP and SMAP, such that we can leave the real one alone?
Ah yes - that will do just fine.
When we get a default/max split, I'll try to remember to take it back out.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
