From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Wei Liu <wl@xen.org>
Subject: Re: [PATCH] x86: extend coverage of HLE "bad page" workaround
Date: Fri, 17 Mar 2023 12:39:26 +0100 [thread overview]
Message-ID: <ZBRRbnBjWHXAM1ug@Air-de-Roger> (raw)
In-Reply-To: <0df22405-bda8-8f4d-63b4-e9c4d57843b1@suse.com>
On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote:
> On 26.05.2020 17:01, Andrew Cooper wrote:
> > On 26/05/2020 14:35, Jan Beulich wrote:
> >> On 26.05.2020 13:17, Andrew Cooper wrote:
> >>> On 26/05/2020 07:49, Jan Beulich wrote:
> >>>> Respective Core Gen10 processor lines are affected, too.
> >>>>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>
> >>>> --- a/xen/arch/x86/mm.c
> >>>> +++ b/xen/arch/x86/mm.c
> >>>> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
> >>>> case 0x000506e0: /* errata SKL167 / SKW159 */
> >>>> case 0x000806e0: /* erratum KBL??? */
> >>>> case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> >>>> + case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> >>>> + case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
> >>> This is marred in complexity.
> >>>
> >>> The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
> >>> moving forwards on any TSX-enabled CPU) includes a confirmation that HLE
> >>> no longer exists/works. This applies to IceLake systems, but possibly
> >>> not their initial release configuration (hence, via a later microcode
> >>> update).
> >>>
> >>> HLE is also disabled in microcode on all older parts for errata reasons,
> >>> so in practice it doesn't exist anywhere now.
> >>>
> >>> I think it is safe to drop this workaround, and this does seem a more
> >>> simple option than encoding which microcode turned HLE off (which sadly
> >>> isn't covered by the spec updates, as even when turned off, HLE is still
> >>> functioning according to its spec of "may speed things up, may do
> >>> nothing"), or the interactions with the CPUID hiding capabilities of
> >>> MSR_TSX_CTRL.
> >> I'm afraid I don't fully follow: For one, does what you say imply HLE is
> >> no longer enumerated in CPUID?
> >
> > No - sadly not. For reasons of "not repeating the Haswell/Broadwell
> > microcode fiasco", the HLE bit will continue to exist and be set.
> > (Although on CascadeLake and later, you can turn it off with MSR_TSX_CTRL.)
> >
> > It was always a weird CPUID bit. You were supposed to put
> > XACQUIRE/XRELEASE prefixes on your legacy locking, and it would be a nop
> > on old hardware and go faster on newer hardware.
> >
> > There is nothing runtime code needs to look at the HLE bit for, except
> > perhaps for UI reporting purposes.
>
> Do you know of some public Intel doc I could reference for all of this,
> which I would kind of need in the description of a patch ...
>
> >> But then this
> >> erratum does not have the usual text effectively meaning that an ucode
> >> update is or will be available to address the issue; instead it says
> >> that BIOS or VMM can reserve the respective address range.
> >
> > This is not surprising at all. Turning off HLE was an unrelated
> > activity, and I bet the link went unnoticed.
> >
> >> This - assuming the alternative you describe is indeed viable - then is surely
> >> a much more intrusive workaround than needed. Which I wouldn't assume
> >> they would suggest in such a case.
> >
> > My suggestion was to drop the workaround, not to complicated it with a
> > microcode revision matrix.
>
> ... doing this? I don't think I've seen any of this in writing so far,
> except by you. (I don't understand how this reply of yours relates to
> what I was saying about the spec update. I understand what you are
> suggesting. I merely tried to express that I'd have expected Intel to
> point out the much easier workaround, rather than just a pretty involved
> one.) Otherwise, may I suggest you make such a patch, to make sure it
> has an adequate description?
Seeing as there seems to be some data missing to justify the commit -
was has Linux done with those erratas?
Thanks, Roger.
next prev parent reply other threads:[~2023-03-17 11:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 6:49 [PATCH] x86: extend coverage of HLE "bad page" workaround Jan Beulich
2020-05-26 11:17 ` Andrew Cooper
2020-05-26 13:35 ` Jan Beulich
2020-05-26 15:01 ` Andrew Cooper
2020-05-26 16:40 ` Jan Beulich
2023-03-17 11:39 ` Roger Pau Monné [this message]
2023-03-20 9:24 ` Jan Beulich
2023-03-21 14:51 ` Andrew Cooper
2023-03-21 15:59 ` Roger Pau Monné
2023-03-21 16:14 ` Andrew Cooper
2023-03-21 16:31 ` Jan Beulich
2023-03-21 14:42 ` Roger Pau Monné
2023-03-21 15:51 ` Jan Beulich
2023-03-21 15:58 ` Roger Pau Monné
2023-03-21 16:03 ` Jan Beulich
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=ZBRRbnBjWHXAM1ug@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).