On 22/04/2025 11:40 am, Frediano Ziglio wrote:
> On Thu, Apr 17, 2025 at 5:19 PM Roger Pau Monne <roger....@citrix.com> wrote:
>> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
>> index 6a680ba38dc9..9d7c6ea297a9 100644
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -380,6 +380,43 @@ static void probe_c3_errata(const struct cpuinfo_x86 *c)
>> }
>> }
>>
>> +/*
>> + * APL30: One use of the MONITOR/MWAIT instruction pair is to allow a
>> logical
>> + * processor to wait in a sleep state until a store to the armed address
>> range
>> + * occurs. Due to this erratum, stores to the armed address range may not
>> + * trigger MWAIT to resume execution.
>> + *
>> + * ICX143: Under complex microarchitectural conditions, a monitor that is
>> armed
>> + * with the MWAIT instruction may not be triggered, leading to a processor
>> + * hang.
>> + *
>> + * LNL030: Problem P-cores may not exit power state Core C6 on monitor hit.
>> + *
>> + * Force the sending of an IPI in those cases.
>> + */
>> +static void probe_mwait_errata(void)
>> +{
>> + static const struct x86_cpu_id models[] = {
>> + /* Apollo Lake */
>> + INTEL_FAM6_MODEL(0x5C),
>> + /* Ice Lake */
>> + INTEL_FAM6_MODEL(0x6A),
>> + INTEL_FAM6_MODEL(0x6C),
> Intel patch for Linux only adds model 0x6a, not 0x6c. Did we manage to
> reproduce on 0x6c? Which patch is more correct? Surely we are on the
> safer side.
It only affects 0x6a, but I can't go into why. Now that Linux is
picking up this workaround, we should follow Dave Hansen managed to get
out of Intel's internal bugtracker on the matter.
~Andrew
