* [PATCH] x86: avoid HPET use also on certain Coffee Lake H
@ 2020-05-25 15:18 Jan Beulich
2020-05-25 15:23 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2020-05-25 15:18 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
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. To be on the safe side, add
both until clarification can be provided by Intel.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -397,10 +397,16 @@ static int64_t __init init_hpet(struct p
* entered PC10.
*/
if ( pci_conf_read16(PCI_SBDF(0, 0, 0, 0),
- PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL &&
- pci_conf_read16(PCI_SBDF(0, 0, 0, 0),
- PCI_DEVICE_ID) == 0x3ec4 )
- hpet_address = 0;
+ PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL )
+ switch ( pci_conf_read16(PCI_SBDF(0, 0, 0, 0),
+ PCI_DEVICE_ID) )
+ {
+ case 0x3e10: /* as per datasheet (4 core variant) */
+ case 0x3e20: /* as per respective Linux commit */
+ case 0x3ec4:
+ hpet_address = 0;
+ break;
+ }
if ( !hpet_address )
printk("Disabling HPET for being unreliable\n");
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: avoid HPET use also on certain Coffee Lake H
2020-05-25 15:18 [PATCH] x86: avoid HPET use also on certain Coffee Lake H Jan Beulich
@ 2020-05-25 15:23 ` Jan Beulich
2020-05-25 17:30 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2020-05-25 15:23 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monné
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. To be on the safe side, add
> both until clarification can be provided by Intel.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
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.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: avoid HPET use also on certain Coffee Lake H
2020-05-25 15:23 ` Jan Beulich
@ 2020-05-25 17:30 ` Andrew Cooper
2020-05-26 5:47 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2020-05-25 17:30 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Wei Liu, Roger Pau Monné
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@suse.com>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: avoid HPET use also on certain Coffee Lake H
2020-05-25 17:30 ` Andrew Cooper
@ 2020-05-26 5:47 ` Jan Beulich
0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2020-05-26 5:47 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu, Roger Pau Monné
On 25.05.2020 19:30, Andrew Cooper wrote:
> 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.
Ah, and I should have checked again before submitting - the pretty new
rev 003 datasheet actually includes all three IDs now. I've adjusted
description and code comments accordingly.
>>> To be on the safe side, add
>>> both until clarification can be provided by Intel.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> 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.
While looking into this a while ago I cam across this as well, but I
couldn't deduce whether entering PC10 is indeed possible _only_ this
way.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-26 5:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-25 15:18 [PATCH] x86: avoid HPET use also on certain Coffee Lake H Jan Beulich
2020-05-25 15:23 ` Jan Beulich
2020-05-25 17:30 ` Andrew Cooper
2020-05-26 5:47 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.