Re: [PATCH] x86/idle: prevent entering C6 with in service interrupts on Intel

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.05.2020 19:24, Roger Pau Monné wrote:
> On Fri, May 08, 2020 at 03:46:08PM +0200, Jan Beulich wrote:
>> On 07.05.2020 15:22, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/cpu/mwait-idle.c
>>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>>> @@ -770,6 +770,9 @@ static void mwait_idle(void)
>>>             return;
>>>     }
>>>  
>>> +   if (cx->type == ACPI_STATE_C3 && errata_c6_isr_workaround())
>>> +           cx = power->safe_state;
>>
>> Here it becomes even more relevant I think that == not be
>> used, as the static tables list deeper C-states; it's just
>> that the SKX table, which also gets used for CLX afaict, has
>> no entries beyond C6-SKX. Others with deeper ones presumably
>> have the deeper C-states similarly affected (or not) by this
>> erratum.
>>
>> For reference, mwait_idle_cpu_init() has
>>
>>              hint = flg2MWAIT(cpuidle_state_table[cstate].flags);
>>              state = MWAIT_HINT2CSTATE(hint) + 1;
>>                 ...
>>              cx->type = state;
>>
>> i.e. the value you compare against is derived from the static
>> table entries. For Nehalem/Westmere this means that what goes
>> under ACPI_STATE_C3 is indeed C6-NHM, and this looks to match
>> for all the non-Atoms, but for none of the Atoms. Now Atoms
>> could easily be unaffected, but (just to take an example) if
>> C6-SNB was affected, surely C7-SNB would be, too.
> 
> Yes, I've adjusted this to use cx->type >= 3 instead. I have to admit
> I'm confused by the name of the states being C6-* while the cstate
> value reported by Xen will be 3 (I would instead expect the type to be
> 6 in order to match the name).

Well, the problem is the disagreement in numbering between ACPI
and what the various CPU specs actually use.

Jan