From: Borislav Petkov <bp@alien8.de>
To: Ashok Raj <ashok.raj@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Tony Luck <tony.luck@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Stefan Talpalaru <stefantalpalaru@yahoo.com>,
David Woodhouse <dwmw2@infradead.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jonathan Corbet <corbet@lwn.net>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Peter Zilstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Martin Pohlack <mpohlack@amazon.de>
Subject: Re: [Patch v3 Part2 4/9] x86/microcode: Do not call apply_microcode() on sibling threads
Date: Thu, 2 Feb 2023 10:40:31 +0100 [thread overview]
Message-ID: <Y9uFD1PQoq0Ktaol@zn.tnic> (raw)
In-Reply-To: <Y9skuAuxozZLDrGB@a4bf019067fa.jf.intel.com>
On Wed, Feb 01, 2023 at 06:51:44PM -0800, Ashok Raj wrote:
> T1 shouldn't be sent down the apply_microcode() path, but instead
> just gather and update the per-cpu info reflecting the current revision.
As I said previously, it doesn't apply the microcode but simply updates
the cached info. The assumption was that T0 would not fail.
> At wait_for_siblings: Each thread can check their rev against the BSP (yes
> BSP can be removed, but we can elect a core leader) and if they are
A core leader?
The one who succeeded in doing the update?
> different we can either warn/taint or pull the plug and panic.
What about SMT=off? How are you gonna handle that? Who's the core leader
there?
What about the other vendor? That hackery of yours needs to be verified
there too.
So this whole deal needs to be analyzed properly. What would happen in
any potential outcome, how should the kernel behave in each case, etc,
etc.
In thinking about the minrev, I can just as well imagine that such
microcode patches which could cause such a failure should be marked and
not loaded late either. But I'm sure you don't want that.
In any case, without a proper analysis and writeup how that new
algorithm is going to look like and behave, this is not going anywhere.
No ad-hoc patches, no let's fix that aspect first.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2023-02-02 9:40 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 21:39 [Patch v3 Part2 0/9] x86/microcode: Declare microcode safe for late loading Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 1/9] x86/microcode: Taint kernel only if microcode loading was successful Ashok Raj
2023-01-31 11:50 ` Borislav Petkov
2023-01-31 16:51 ` Ashok Raj
2023-01-31 20:20 ` Borislav Petkov
2023-01-31 22:54 ` Ashok Raj
2023-02-01 12:44 ` Borislav Petkov
2023-02-01 15:42 ` Ashok Raj
2023-02-01 21:47 ` Ashok Raj
2023-02-01 22:06 ` Borislav Petkov
2023-02-01 22:19 ` Ashok Raj
2023-02-01 22:26 ` Borislav Petkov
2023-01-31 12:17 ` Li, Aubrey
2023-01-31 15:32 ` Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 2/9] x86/microcode: Report invalid writes to reload sysfs file Ashok Raj
2023-01-31 15:57 ` [tip: x86/microcode] x86/microcode: Allow only "1" as a late reload trigger value tip-bot2 for Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 3/9] x86/microcode/intel: Fix collect_cpu_info() to reflect current microcode Ashok Raj
2023-01-31 16:48 ` Borislav Petkov
2023-01-31 17:34 ` Luck, Tony
2023-01-31 17:41 ` Ashok Raj
2023-01-31 20:40 ` Borislav Petkov
2023-01-31 20:49 ` Luck, Tony
2023-01-31 21:08 ` Borislav Petkov
2023-01-31 22:32 ` Ashok Raj
2023-01-31 22:43 ` Luck, Tony
2023-02-01 12:53 ` Borislav Petkov
2023-02-01 15:13 ` Ashok Raj
2023-02-01 15:25 ` Borislav Petkov
2023-02-01 16:15 ` Luck, Tony
2023-02-01 19:13 ` Dave Hansen
2023-02-01 19:32 ` Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 4/9] x86/microcode: Do not call apply_microcode() on sibling threads Ashok Raj
2023-02-01 22:21 ` Dave Hansen
2023-02-01 22:40 ` Borislav Petkov
2023-02-02 2:51 ` Ashok Raj
2023-02-02 9:40 ` Borislav Petkov [this message]
2023-02-02 16:34 ` Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 5/9] x86/microcode: Move late load warning to the same function that taints kernel Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 6/9] x86/microcode/intel: Add minimum required revision to microcode header Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 7/9] x86/microcode: Add a generic mechanism to declare support for minrev Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 8/9] x86/microcode/intel: Drop wbinvd() from microcode loading Ashok Raj
2023-01-30 21:39 ` [Patch v3 Part2 9/9] x86/microcode: Provide an option to override minrev enforcement Ashok Raj
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=Y9uFD1PQoq0Ktaol@zn.tnic \
--to=bp@alien8.de \
--cc=Andrew.Cooper3@citrix.com \
--cc=alison.schofield@intel.com \
--cc=ashok.raj@intel.com \
--cc=benh@kernel.crashing.org \
--cc=boris.ostrovsky@oracle.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mpohlack@amazon.de \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=reinette.chatre@intel.com \
--cc=stefantalpalaru@yahoo.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.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