From: Ashok Raj <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
LKML Mailing List <linux-kernel@vger.kernel.org>,
X86-kernel <x86@kernel.org>,
Tom Lendacky <thomas.lendacky@amd.com>,
Arjan van de Ven <arjan.van.de.ven@intel.com>,
Jacob Jun Pan <jacob.jun.pan@intel.com>,
Ashok Raj <ashok.raj@intel.com>
Subject: [PATCH 03/13] x86/microcode/intel: Fix a hang if early loading microcode fails
Date: Fri, 14 Oct 2022 13:09:03 -0700 [thread overview]
Message-ID: <20221014200913.14644-4-ashok.raj@intel.com> (raw)
In-Reply-To: <20221014200913.14644-1-ashok.raj@intel.com>
When early loading of microcode fails for any reason other than the wrong
family-model-stepping, Linux can get into an infinite loop retrying the
same failed load.
A single retry is needed to handle any mixed stepping case.
Assume we have a microcode that fails to load for some reason.
load_ucode_ap() seems to retry if the loading fails. But it searches for
a new rev, but ends up finding the same copy. Hence it appears to repeat
the same load, retry loop for ever.
We can fix it as follows.
1) When the load_ucode_intel_bsp() fails, record the revision that failed.
2) In load_ucode_intel_ap() check if AP is same FMS as BP, and the code
that failed earlier isn't going to apply anyway. So use the saved
information to abort loading on AP's altogether.
load_ucode_intel_ap()
{
..
reget:
if (!*iup) {
patch = __load_ucode_intel(&uci);
^^^^^ Finds the same patch every time.
if (!patch)
return;
*iup = patch;
}
uci.mc = *iup;
if (apply_microcode_early(&uci, true)) {
^^^^^^^^^^^^ apply fails
/* Mixed-silicon system? Try to refetch the proper patch: */
*iup = NULL;
goto reget;
^^^^^ Rince repeat.
}
}
Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
arch/x86/kernel/cpu/microcode/intel.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index cf1e2c30b230..0f7e4ba05c39 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -606,6 +606,7 @@ void __init load_ucode_intel_bsp(void)
{
struct microcode_intel *patch;
struct ucode_cpu_info uci;
+ int rev, ret;
patch = __load_ucode_intel(&uci);
if (!patch)
@@ -613,13 +614,18 @@ void __init load_ucode_intel_bsp(void)
uci.mc = patch;
- apply_microcode_early(&uci, true);
+ ret = apply_microcode_early(&uci, true);
+ if (ret) {
+ rev = patch->hdr.rev;
+ pr_err("Revision 0x%x failed during early loading\n", rev);
+ }
}
void load_ucode_intel_ap(void)
{
struct microcode_intel *patch, **iup;
struct ucode_cpu_info uci;
+ bool retried = false;
if (IS_ENABLED(CONFIG_X86_32))
iup = (struct microcode_intel **) __pa_nodebug(&intel_ucode_patch);
@@ -638,9 +644,13 @@ void load_ucode_intel_ap(void)
uci.mc = *iup;
if (apply_microcode_early(&uci, true)) {
+ if (retried)
+ return;
+
/* Mixed-silicon system? Try to refetch the proper patch: */
*iup = NULL;
+ retried = true;
goto reget;
}
}
--
2.34.1
next prev parent reply other threads:[~2022-10-14 20:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 20:09 [PATCH 00/13] Make microcode loading more robust Ashok Raj
2022-10-14 20:09 ` [PATCH 01/13] x86/microcode/intel: Print old and new rev after early microcode update Ashok Raj
2022-10-19 10:12 ` Borislav Petkov
2022-10-19 13:30 ` Ashok Raj
2022-10-14 20:09 ` [PATCH 02/13] x86/microcode: Do not load from filesystem for CPU hot add Ashok Raj
2022-10-19 17:52 ` Borislav Petkov
2022-10-19 17:54 ` [PATCH 1/5] x86/microcode: Rip out the subsys interface gunk Borislav Petkov
2022-10-19 17:54 ` [PATCH 2/5] x86/microcode: Simplify init path even more Borislav Petkov
2022-10-19 19:22 ` Ashok Raj
2022-10-19 19:37 ` Borislav Petkov
2022-10-20 8:18 ` Borislav Petkov
2022-10-20 15:04 ` Ashok Raj
2022-10-21 9:28 ` Borislav Petkov
2022-10-21 10:21 ` Ashok Raj
2022-10-21 10:57 ` Borislav Petkov
2022-10-21 11:39 ` Ashok Raj
2022-10-21 13:30 ` Borislav Petkov
2022-10-19 17:54 ` [PATCH 3/5] x86/microcode: Kill refresh_fw Borislav Petkov
2022-10-19 17:54 ` [PATCH 4/5] x86/microcode: Do some minor fixups Borislav Petkov
2022-10-19 17:54 ` [PATCH 5/5] x86/microcode: Drop struct ucode_cpu_info.valid Borislav Petkov
2022-10-20 15:48 ` [PATCH -v2 1/5] x86/microcode: Rip out the subsys interface gunk Borislav Petkov
2022-10-14 20:09 ` Ashok Raj [this message]
2022-10-14 20:09 ` [PATCH 04/13] x86/x2apic: Support x2apic self IPI with NMI_VECTOR Ashok Raj
2022-10-19 15:36 ` Ashok Raj
2022-10-14 20:09 ` [PATCH 05/13] x86/microcode: Place siblings in NMI loop while update in progress Ashok Raj
2022-10-14 20:09 ` [PATCH 06/13] x86/microcode: Rename refresh_fw to late_loading Ashok Raj
2022-10-14 20:09 ` [PATCH 07/13] x86/microcode: Move late-load warning to earlier where kernel taint happens Ashok Raj
2022-10-14 20:09 ` [PATCH 08/13] x86/microcode/intel: Add minimum required revision to microcode header Ashok Raj
2022-10-14 20:09 ` [PATCH 09/13] x86/microcode: Add a generic mechanism to declare support for minrev Ashok Raj
2022-10-19 4:03 ` Huang, Kai
2022-10-19 12:48 ` Ashok Raj
2022-10-14 20:09 ` [PATCH 10/13] x86/microcode/intel: Drop wbinvd() from microcode loading Ashok Raj
2022-10-14 20:09 ` [PATCH 11/13] x86/microcode: Display revisions only when update is successful Ashok Raj
2022-10-14 20:09 ` [PATCH 12/13] x86/mce: Warn of a microcode update is in progress when MCE arrives Ashok Raj
2022-10-14 20:09 ` [PATCH 13/13] x86/microcode/intel: Add ability to update microcode even if rev is unchanged Ashok Raj
2022-10-19 15:51 ` 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=20221014200913.14644-4-ashok.raj@intel.com \
--to=ashok.raj@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=jacob.jun.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--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