* [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
@ 2019-11-22 12:46 Jan Beulich
2019-11-22 12:50 ` Andrew Cooper
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2019-11-22 12:46 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross, Andrew Cooper, Wei Liu, Roger Pau Monné
Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
"Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
PC10, which in consequence marks TSC as unstable because HPET is used as
watchdog clocksource for TSC."
Follow this for Xen as well. Looking at its patch context made me notice
they have a pre-existing quirk for Bay Trail as well. The comment there,
however, points at a Cherry Trail document. Looking at the datasheets of
both, there appear to be similar issues, so go beyond Linux'es coverage
and exclude both. Also key the disable on the PCI IDs of the actual
affected devices, rather than those of 00:00.0.
Apply the workarounds only when the use of HPET was not explicitly
requested on the command line and when use of (deep) C-states was not
disabled.
Adjust a few types in touched or nearby code at the same time.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -18,6 +18,7 @@
#include <xen/timer.h>
#include <xen/smp.h>
#include <xen/irq.h>
+#include <xen/pci_ids.h>
#include <xen/softirq.h>
#include <xen/efi.h>
#include <xen/cpuidle.h>
@@ -367,12 +368,41 @@ static u64 read_hpet_count(void)
return hpet_read32(HPET_COUNTER);
}
-static s64 __init init_hpet(struct platform_timesource *pts)
+static int64_t __init init_hpet(struct platform_timesource *pts)
{
- u64 hpet_rate = hpet_setup(), start;
- u32 count, target;
+ uint64_t hpet_rate, start;
+ uint32_t count, target;
- if ( hpet_rate == 0 )
+ if ( hpet_address && strcmp(opt_clocksource, pts->id) &&
+ cpuidle_using_deep_cstate() )
+ {
+ if ( pci_conf_read16(PCI_SBDF(0, 0, 0x1f, 0),
+ PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL )
+ switch ( pci_conf_read16(PCI_SBDF(0, 0, 0x1f, 0), PCI_DEVICE_ID) )
+ {
+ /* HPET on Bay Trail platforms will halt in deep C states. */
+ case 0x0f1c:
+ /* HPET on Cherry Trail platforms will halt in deep C states. */
+ case 0x229c:
+ hpet_address = 0;
+ break;
+ }
+
+ /*
+ * Some Coffee Lake platforms have a skewed HPET timer once the SoCs
+ * 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;
+
+ if ( !hpet_address )
+ printk("Disabling HPET for being unreliable\n");
+ }
+
+ if ( (hpet_rate = hpet_setup()) == 0 )
return 0;
pts->frequency = hpet_rate;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 12:46 [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms Jan Beulich
@ 2019-11-22 12:50 ` Andrew Cooper
2019-11-22 12:57 ` Jan Beulich
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cooper @ 2019-11-22 12:50 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org
Cc: Juergen Gross, Wei Liu, Roger Pau Monné
On 22/11/2019 12:46, Jan Beulich wrote:
> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>
> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
> PC10, which in consequence marks TSC as unstable because HPET is used as
> watchdog clocksource for TSC."
>
> Follow this for Xen as well. Looking at its patch context made me notice
> they have a pre-existing quirk for Bay Trail as well. The comment there,
> however, points at a Cherry Trail document. Looking at the datasheets of
> both, there appear to be similar issues, so go beyond Linux'es coverage
> and exclude both. Also key the disable on the PCI IDs of the actual
> affected devices, rather than those of 00:00.0.
>
> Apply the workarounds only when the use of HPET was not explicitly
> requested on the command line and when use of (deep) C-states was not
> disabled.
>
> Adjust a few types in touched or nearby code at the same time.
Reported-by ?
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 12:50 ` Andrew Cooper
@ 2019-11-22 12:57 ` Jan Beulich
2019-11-22 12:58 ` Andrew Cooper
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2019-11-22 12:57 UTC (permalink / raw)
To: Andrew Cooper
Cc: Juergen Gross, xen-devel@lists.xenproject.org, Wei Liu,
Roger Pau Monné
On 22.11.2019 13:50, Andrew Cooper wrote:
> On 22/11/2019 12:46, Jan Beulich wrote:
>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>
>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>> PC10, which in consequence marks TSC as unstable because HPET is used as
>> watchdog clocksource for TSC."
>>
>> Follow this for Xen as well. Looking at its patch context made me notice
>> they have a pre-existing quirk for Bay Trail as well. The comment there,
>> however, points at a Cherry Trail document. Looking at the datasheets of
>> both, there appear to be similar issues, so go beyond Linux'es coverage
>> and exclude both. Also key the disable on the PCI IDs of the actual
>> affected devices, rather than those of 00:00.0.
>>
>> Apply the workarounds only when the use of HPET was not explicitly
>> requested on the command line and when use of (deep) C-states was not
>> disabled.
>>
>> Adjust a few types in touched or nearby code at the same time.
>
> Reported-by ?
The Linux commit has a Suggested-by, but no Reported-by. Do you
want me to copy that one? Or else do you have any suggestion as
to who the reporter was?
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Thanks.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 12:57 ` Jan Beulich
@ 2019-11-22 12:58 ` Andrew Cooper
2019-11-22 13:36 ` Jan Beulich
2019-11-22 23:10 ` Andreas Kinzler
0 siblings, 2 replies; 8+ messages in thread
From: Andrew Cooper @ 2019-11-22 12:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, xen-devel@lists.xenproject.org, Wei Liu,
Roger Pau Monné
On 22/11/2019 12:57, Jan Beulich wrote:
> On 22.11.2019 13:50, Andrew Cooper wrote:
>> On 22/11/2019 12:46, Jan Beulich wrote:
>>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>>
>>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>> PC10, which in consequence marks TSC as unstable because HPET is used as
>>> watchdog clocksource for TSC."
>>>
>>> Follow this for Xen as well. Looking at its patch context made me notice
>>> they have a pre-existing quirk for Bay Trail as well. The comment there,
>>> however, points at a Cherry Trail document. Looking at the datasheets of
>>> both, there appear to be similar issues, so go beyond Linux'es coverage
>>> and exclude both. Also key the disable on the PCI IDs of the actual
>>> affected devices, rather than those of 00:00.0.
>>>
>>> Apply the workarounds only when the use of HPET was not explicitly
>>> requested on the command line and when use of (deep) C-states was not
>>> disabled.
>>>
>>> Adjust a few types in touched or nearby code at the same time.
>> Reported-by ?
> The Linux commit has a Suggested-by, but no Reported-by. Do you
> want me to copy that one? Or else do you have any suggestion as
> to who the reporter was?
Well - this patch was identified by someone on xen-devel, which I
presume was your basis for looking into it.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 12:58 ` Andrew Cooper
@ 2019-11-22 13:36 ` Jan Beulich
2019-11-22 23:10 ` Andreas Kinzler
1 sibling, 0 replies; 8+ messages in thread
From: Jan Beulich @ 2019-11-22 13:36 UTC (permalink / raw)
To: Andrew Cooper
Cc: Juergen Gross, xen-devel@lists.xenproject.org, Wei Liu,
Roger Pau Monné
On 22.11.2019 13:58, Andrew Cooper wrote:
> On 22/11/2019 12:57, Jan Beulich wrote:
>> On 22.11.2019 13:50, Andrew Cooper wrote:
>>> On 22/11/2019 12:46, Jan Beulich wrote:
>>>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>>>
>>>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>>> PC10, which in consequence marks TSC as unstable because HPET is used as
>>>> watchdog clocksource for TSC."
>>>>
>>>> Follow this for Xen as well. Looking at its patch context made me notice
>>>> they have a pre-existing quirk for Bay Trail as well. The comment there,
>>>> however, points at a Cherry Trail document. Looking at the datasheets of
>>>> both, there appear to be similar issues, so go beyond Linux'es coverage
>>>> and exclude both. Also key the disable on the PCI IDs of the actual
>>>> affected devices, rather than those of 00:00.0.
>>>>
>>>> Apply the workarounds only when the use of HPET was not explicitly
>>>> requested on the command line and when use of (deep) C-states was not
>>>> disabled.
>>>>
>>>> Adjust a few types in touched or nearby code at the same time.
>>> Reported-by ?
>> The Linux commit has a Suggested-by, but no Reported-by. Do you
>> want me to copy that one? Or else do you have any suggestion as
>> to who the reporter was?
>
> Well - this patch was identified by someone on xen-devel, which I
> presume was your basis for looking into it.
No, it was me spotting the Linux commit in the stable 5.3 ChangeLog.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 12:58 ` Andrew Cooper
2019-11-22 13:36 ` Jan Beulich
@ 2019-11-22 23:10 ` Andreas Kinzler
2019-11-25 10:15 ` Jan Beulich
1 sibling, 1 reply; 8+ messages in thread
From: Andreas Kinzler @ 2019-11-22 23:10 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich
Cc: Juergen Gross, xen-devel@lists.xenproject.org, Wei Liu,
Roger Pau Monné
On 22.11.2019 13:58, Andrew Cooper wrote:
> On 22/11/2019 12:57, Jan Beulich wrote:
>> On 22.11.2019 13:50, Andrew Cooper wrote:
>>> On 22/11/2019 12:46, Jan Beulich wrote:
>>>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>>>
>>>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>>> PC10, which in consequence marks TSC as unstable because HPET is used as
>>>> watchdog clocksource for TSC."
>>>>
>>>> Adjust a few types in touched or nearby code at the same time.
>>> Reported-by ?
>> The Linux commit has a Suggested-by, but no Reported-by. Do you
>> want me to copy that one? Or else do you have any suggestion as
>> to who the reporter was?
> Well - this patch was identified by someone on xen-devel, which I
> presume was your basis for looking into it.
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00662.html
BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with
Intel which combinations are really affected.
Regards Andreas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
2019-11-22 23:10 ` Andreas Kinzler
@ 2019-11-25 10:15 ` Jan Beulich
2019-11-25 12:46 ` Andreas Kinzler
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2019-11-25 10:15 UTC (permalink / raw)
To: Andreas Kinzler
Cc: Juergen Gross, Andrew Cooper, xen-devel@lists.xenproject.org,
Wei Liu, Roger Pau Monné
On 23.11.2019 00:10, Andreas Kinzler wrote:
> BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with
> Intel which combinations are really affected.
Are you saying you observed the same issue on such a (server processor)
system as well? Neither its datasheet nor its specification update
(which I specifically downloaded and looked through just because of your
remark) have any mention of a similar issue. I also take it that the
code comment inherited from Linux says "SoCs" for a reason.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-11-25 12:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-22 12:46 [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms Jan Beulich
2019-11-22 12:50 ` Andrew Cooper
2019-11-22 12:57 ` Jan Beulich
2019-11-22 12:58 ` Andrew Cooper
2019-11-22 13:36 ` Jan Beulich
2019-11-22 23:10 ` Andreas Kinzler
2019-11-25 10:15 ` Jan Beulich
2019-11-25 12:46 ` Andreas Kinzler
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.