Re: [PATCH] x86: avoid HPET use also on certain Coffee Lake H

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/05/2020 16:23, Jan Beulich wrote:
> On 25.05.2020 17:18, Jan Beulich wrote:
>> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says
>>
>> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET
>>  timer once the SoCs entered PC10."
>>
>> Again follow this for Xen as well, noting though that even the
>> pre-existing PCI ID refers to a H-processor line variant (the 6-core
>> one). It is also suspicious that the datasheet names 0x3e10 for the
>> 4-core variant, while the Linux commit specifies 0x3e20, which I haven't
>> been able to locate in any datasheet yet.

3e20 is the host bridge ID for CFL-R (Gen 9) Core i9 (8c/16t) as found
in the Dell XPS 15 7590 amongst other things.

As such, it is a generation later than CFL.

>>  To be on the safe side, add
>> both until clarification can be provided by Intel.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Given the nature of issue (a power efficiently "feature" rather than a
bug), it will likely affect everything in a couple of generations worth
of CPUs.

The issue may not actually affect Xen yet, because I don't expect we've
got S0ix working yet.  It is only a problem on entry to S0i2/3 where the
HPET is halted.

> I'd like to note that I've been sitting on this for several months,
> hoping to be able to submit with less uncertainty. I shall further
> note that I'm sitting on a similar Ice Lake patch, triggered by
> seeing Linux'es e0748539e3d594dd26f0d27a270f14720b22a406. The
> situation seems even worse there - I can't make datasheet and
> Linux commit match even remotely, PCI-ID-wise. I didn't think it
> makes sense to submit a patch in such a case.

0x8a12 is an ID in the middle of a load of Ice Lake IDs, according to
the PCI-ID database, but there isn't entry specifically for it.

I can't find a datasheet either for it.

~Andrew