From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] x86: avoid HPET use also on certain Coffee Lake H
Date: Tue, 26 May 2020 07:47:59 +0200 [thread overview]
Message-ID: <6fdaf1fc-8c3d-fff9-fb65-174caad5afeb@suse.com> (raw)
In-Reply-To: <5f5483cc-a8e8-51a3-6c47-5b061ff97108@citrix.com>
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
prev parent reply other threads:[~2020-05-26 5:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6fdaf1fc-8c3d-fff9-fb65-174caad5afeb@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.