From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: ...
Date: Mon, 21 Oct 2019 22:53:10 -0700 [thread overview]
Message-ID: <20191022055310.GA12194@guptapadev.amr> (raw)
In-Reply-To: <4f718d5b-b578-ddd9-9898-36c6088a4615@redhat.com>
On Tue, Oct 22, 2019 at 12:10:31AM -0400, speck for Jon Masters wrote:
> Subject: Re: [PATCH v7 07/10] TAAv7 7
> On 10/21/19 4:29 PM, speck for Pawan Gupta wrote:
> > From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > Subject: [PATCH v7 07/10] x86/tsx: Add "auto" option to TSX cmdline parameter
> >
> > Platforms which are not affected by X86_BUG_TAA may want the TSX feature
> > enabled. Add "auto" option to the TSX cmdline parameter. When tsx=auto
> > disable TSX when X86_BUG_TAA is present, otherwise enable TSX.
>
> Earlier, you do this:
>
> + if (!(ia32_cap & ARCH_CAP_TAA_NO) &&
> + (boot_cpu_has(X86_FEATURE_RTM) ||
> + (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
> + setup_force_cpu_bug(X86_BUG_TAA);
>
> Per the other discussion, I think you want to double check if tsx=auto
> is doing what folks want it to do, because currently I think auto still
> has the semantics of turning off TSX on everything, rather than just
> those cases where a VERW mitigation won't suffice/is in use.
tsx=auto can only disable TSX on current CPUs(MDS_NO=1) because older
CPUs(MDS_NO=0) wont get TSX_CTRL_MSR.
On older CPUs tsx_init() would simply do nothing because of lack of TSX_CTRL.
void __init tsx_init(void)
{
if (!tsx_ctrl_is_supported())
return;
[...]
>
> (see Thomas's update to the "Re: [PATCH v5 08/11] TAAv5 8" diagram)
MDS_NO MD_CLEAR TSX_CTRL_MSR
0 0 0 Vulnerable (needs ucode)
0 1 0 MDS and TAA mitigated via VERW
1 1 0 MDS fixed, TAA vulnerable if TSX enabled
because MD_CLEAR has no meaning and
VERW is not guaranteed to clear buffers
1 X 1 MDS fixed, TAA can be mitigated by
VERW or TSX_CTRL_MSR
Thomas's table sums up the mitigation status.
>
> It seems that it's a good time to double check if that's what everyone
> on the distro side is expecting, namely "tsx=auto will disable TSX
> automatically on those parts impacted by TAA for which VERW mitigation
> is not available".
Microcode update for MDS_NO=1 parts adds both TSX_CTRL and VERW
mitigation at the same time. It is for the OS to choose(tsx=) which
mitigation to deploy.
For MDS_NO=0 CPUs:
VERW mitigation will be deployed.
tsx= is ineffective, for the lack of TSX_CTRL.
For MDS_NO=1 CPUs:
If OS chooses tsx=on, VERW mitigation will be deployed.
If OS chooses tsx=auto, TSX will be disabled.
If OS chooses tsx=off, TSX will be disabled (for TAA_NO=1 as well).
More details on tsx=auto:
+----------+----------+----------------+---------------+--------------+-------------------+
| MSR_IA32_ARCH_CAPABILITIES bits | Result with cmdline tsx=auto |
+----------+----------+----------------+---------------+--------------+-------------------+
| TAA_NO | MDS_NO | TSX_CTRL_MSR | VERW clears | TSX state | TAA mitigation |
| | | | CPU buffers | after bootup | |
+==========+==========+================+===============+==============+===================+
| 0 | 0 | 0 | Yes | HW default | Same as MDS |
+----------+----------+----------------+---------------+--------------+-------------------+
| 0 | 0 | 1 | Invalid case | Invalid case | Invalid case |
+----------+----------+----------------+---------------+--------------+-------------------+
| 0 | 1 | 0 | No | HW default | Need ucode update |
+----------+----------+----------------+---------------+--------------+-------------------+
| 0 | 1 | 1 | Yes | TSX disabled | TSX disabled |
+----------+----------+----------------+---------------+--------------+-------------------+
| 1 | X | 1 | X | TSX enabled | None needed |
+----------+----------+----------------+---------------+--------------+-------------------+
Note: MDS_NO=0 and TSX_CTRL_MSR=1 is an invalid case above, which
prevents tsx=auto from disabling TSX in older CPUs.
>This seems to reduce the set where we end up
> disabling TSX essentially to a few very recent processors (e.g.
> CascadeLake some second gen, Bx stepping?). If that's what we are all
> expecting/are planning to do, I suspect Red Hat would go with tsx=auto
> as a default since the set of impacted processors can be documented.
>
> Anyway, auto isn't right yet.
Below change isn't required as per the above explanation, but I can add
it if adds clarity. Or maybe cover with code comments.
diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c
index 0969e6e9dff3..7b567ca266c9 100644
--- a/arch/x86/kernel/cpu/tsx.c
+++ b/arch/x86/kernel/cpu/tsx.c
@@ -70,7 +70,8 @@ static bool __init tsx_ctrl_is_supported(void)
static enum tsx_ctrl_states x86_get_tsx_auto_mode(void)
{
- if (boot_cpu_has_bug(X86_BUG_TAA))
+ if (boot_cpu_has_bug(X86_BUG_TAA) &&
+ (ARCH_CAP_MDS_NO & x86_read_arch_cap_msr()))
return TSX_CTRL_DISABLE;
return TSX_CTRL_ENABLE;
next prev parent reply other threads:[~2019-10-22 5:59 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 20:22 [MODERATED] [PATCH v7 00/10] TAAv7 0 Pawan Gupta
2019-10-21 20:23 ` [MODERATED] [PATCH v7 01/10] TAAv7 1 Pawan Gupta
2019-10-21 20:24 ` [MODERATED] [PATCH v7 02/10] TAAv7 2 Pawan Gupta
2019-10-21 20:25 ` [MODERATED] [PATCH v7 03/10] TAAv7 3 Pawan Gupta
2019-10-21 20:26 ` [MODERATED] [PATCH v7 04/10] TAAv7 4 Pawan Gupta
2019-10-21 20:27 ` [MODERATED] [PATCH v7 05/10] TAAv7 5 Pawan Gupta
2019-10-21 20:28 ` [MODERATED] [PATCH v7 06/10] TAAv7 6 Pawan Gupta
2019-10-21 20:29 ` [MODERATED] [PATCH v7 07/10] TAAv7 7 Pawan Gupta
2019-10-21 20:30 ` [MODERATED] [PATCH v7 08/10] TAAv7 8 Pawan Gupta
2019-10-21 20:31 ` [MODERATED] [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-21 20:32 ` [MODERATED] [PATCH v7 10/10] TAAv7 10 Pawan Gupta
2019-10-21 21:32 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Andy Lutomirski
2019-10-21 23:06 ` Andrew Cooper
2019-10-22 0:34 ` Pawan Gupta
2019-10-22 4:10 ` [MODERATED] Jon Masters
2019-10-22 5:53 ` Pawan Gupta [this message]
2019-10-22 7:58 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 07/10] TAAv7 7 Michal Hocko
2019-10-22 16:55 ` [MODERATED] " Pawan Gupta
2019-10-22 8:00 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-22 8:15 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 03/10] TAAv7 3 Michal Hocko
2019-10-22 14:42 ` Josh Poimboeuf
2019-10-22 16:48 ` [MODERATED] " Pawan Gupta
2019-10-22 17:01 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-22 17:35 ` Josh Poimboeuf
2019-10-22 14:38 ` [MODERATED] " Borislav Petkov
2019-10-22 16:58 ` Pawan Gupta
2019-10-22 14:48 ` Borislav Petkov
2019-10-22 17:00 ` Pawan Gupta
2019-10-22 17:16 ` [MODERATED] " Borislav Petkov
2019-10-22 18:07 ` [MODERATED] " Pawan Gupta
2019-10-22 15:07 ` Borislav Petkov
2019-10-22 18:36 ` Pawan Gupta
2019-10-22 18:59 ` [MODERATED] " Borislav Petkov
2019-10-22 16:51 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 17:02 ` Borislav Petkov
2019-10-22 18:00 ` Pawan Gupta
2019-10-22 18:12 ` [MODERATED] " Borislav Petkov
2019-10-22 19:16 ` Luck, Tony
2019-10-22 19:28 ` [MODERATED] " Borislav Petkov
2019-10-22 20:02 ` Luck, Tony
2019-10-22 20:48 ` [MODERATED] Jon Masters
2019-10-22 20:54 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 21:38 ` Josh Poimboeuf
2019-10-22 21:46 ` Borislav Petkov
2019-10-22 22:06 ` Josh Poimboeuf
2019-10-22 22:13 ` Borislav Petkov
2019-10-22 17:44 ` Pawan Gupta
2019-10-22 19:04 ` [MODERATED] " Borislav Petkov
2019-10-22 21:29 ` [MODERATED] " Pawan Gupta
2019-10-22 21:53 ` Borislav Petkov
2019-10-22 22:05 ` Borislav Petkov
2019-10-23 0:27 ` Pawan Gupta
2019-10-23 5:25 ` Pawan Gupta
2019-10-23 6:46 ` Borislav Petkov
2019-10-23 13:28 ` Pawan Gupta
2019-10-23 14:39 ` Borislav Petkov
2019-10-23 1:33 ` Pawan Gupta
2019-10-23 6:48 ` Borislav Petkov
2019-10-22 17:25 ` [MODERATED] Re: [PATCH v7 01/10] TAAv7 1 Josh Poimboeuf
2019-10-23 9:26 ` Borislav Petkov
2019-10-22 17:26 ` Josh Poimboeuf
2019-10-22 20:44 ` [MODERATED] Jon Masters
2019-10-22 17:47 ` [MODERATED] Re: [PATCH v7 03/10] TAAv7 3 Josh Poimboeuf
2019-10-22 18:39 ` [MODERATED] Re: [PATCH v7 10/10] TAAv7 10 Josh Poimboeuf
2019-10-23 7:24 ` Borislav Petkov
2019-10-22 21:20 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Josh Poimboeuf
2019-10-22 21:35 ` Andrew Cooper
2019-10-22 21:44 ` Josh Poimboeuf
2019-10-22 22:03 ` Andrew Cooper
2019-10-23 1:16 ` Josh Poimboeuf
2019-10-23 15:46 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Borislav Petkov
2019-10-23 17:11 ` Josh Poimboeuf
2019-10-23 21:49 ` Borislav Petkov
2019-10-23 22:12 ` Pawan Gupta
2019-10-24 14:08 ` Borislav Petkov
[not found] ` <5dae165e.1c69fb81.4beee.e271SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-24 20:53 ` [MODERATED] Re: [PATCH v7 06/10] TAAv7 6 Paolo Bonzini
2019-10-24 21:00 ` Luck, Tony
2019-10-24 21:33 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2019-02-19 15:58 [MODERATED] [PATCH 0/4] walnut 0 Peter Zijlstra
2019-02-19 15:58 ` [MODERATED] [PATCH 4/4] walnut 4 Peter Zijlstra
2019-02-19 18:49 ` [MODERATED] Linus Torvalds
2019-02-20 14:37 ` Peter Zijlstra
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=20191022055310.GA12194@guptapadev.amr \
--to=pawan.kumar.gupta@linux.intel.com \
--cc=speck@linutronix.de \
/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).