public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ashok Raj <ashok.raj@intel.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Arjan van de Ven <arjan.van.de.ven@intel.com>,
	Jacob Jun Pan <jacob.jun.pan@intel.com>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/5] x86/microcode: Simplify init path even more
Date: Wed, 19 Oct 2022 19:54:23 +0200	[thread overview]
Message-ID: <20221019175426.31025-2-bp@alien8.de> (raw)
In-Reply-To: <20221019175426.31025-1-bp@alien8.de>

From: Borislav Petkov <bp@suse.de>

Get rid of all the IPI-sending functions and their wrappers and use
those which are supposed to be called on each CPU.

Thus:

- microcode_init_cpu() gets called on each CPU on init, applying any new
  microcode that the driver might've found on the filesystem.

- mc_cpu_starting() simply tries to apply cached microcode as this is
  the cpuhp starting callback which gets called on CPU resume too.

And since the driver init function is a late initcall, there is
filesystem by then so a new firmware load attempt can simply be done. In
case a new one is there. Which is weird to begin with - how would the
initrd contain an older revision than what's on the fs since former gets
created by using the blobs from the filesystem.

Oh well, it is cheap to do so why not...

Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kernel/cpu/microcode/core.c | 127 +++++----------------------
 1 file changed, 23 insertions(+), 104 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index a3aedc93afd9..0aa6609e748c 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -319,60 +319,6 @@ void reload_early_microcode(void)
 	}
 }
 
-static void collect_cpu_info_local(void *arg)
-{
-	struct cpu_info_ctx *ctx = arg;
-
-	ctx->err = microcode_ops->collect_cpu_info(smp_processor_id(),
-						   ctx->cpu_sig);
-}
-
-static int collect_cpu_info_on_target(int cpu, struct cpu_signature *cpu_sig)
-{
-	struct cpu_info_ctx ctx = { .cpu_sig = cpu_sig, .err = 0 };
-	int ret;
-
-	ret = smp_call_function_single(cpu, collect_cpu_info_local, &ctx, 1);
-	if (!ret)
-		ret = ctx.err;
-
-	return ret;
-}
-
-static int collect_cpu_info(int cpu)
-{
-	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-	int ret;
-
-	memset(uci, 0, sizeof(*uci));
-
-	ret = collect_cpu_info_on_target(cpu, &uci->cpu_sig);
-	if (!ret)
-		uci->valid = 1;
-
-	return ret;
-}
-
-static void apply_microcode_local(void *arg)
-{
-	enum ucode_state *err = arg;
-
-	*err = microcode_ops->apply_microcode(smp_processor_id());
-}
-
-static int apply_microcode_on_target(int cpu)
-{
-	enum ucode_state err;
-	int ret;
-
-	ret = smp_call_function_single(cpu, apply_microcode_local, &err, 1);
-	if (!ret) {
-		if (err == UCODE_ERROR)
-			ret = 1;
-	}
-	return ret;
-}
-
 /* fake device for request_firmware */
 static struct platform_device	*microcode_pdev;
 
@@ -458,7 +404,7 @@ static int __reload_late(void *info)
 	 * below.
 	 */
 	if (cpumask_first(topology_sibling_cpumask(cpu)) == cpu)
-		apply_microcode_local(&err);
+		err = microcode_ops->apply_microcode(cpu);
 	else
 		goto wait_for_siblings;
 
@@ -480,7 +426,7 @@ static int __reload_late(void *info)
 	 * revision.
 	 */
 	if (cpumask_first(topology_sibling_cpumask(cpu)) != cpu)
-		apply_microcode_local(&err);
+		err = microcode_ops->apply_microcode(cpu);
 
 	return ret;
 }
@@ -589,51 +535,15 @@ static void microcode_fini_cpu(int cpu)
 		microcode_ops->microcode_fini_cpu(cpu);
 }
 
-static enum ucode_state microcode_resume_cpu(int cpu)
-{
-	if (apply_microcode_on_target(cpu))
-		return UCODE_ERROR;
-
-	pr_debug("CPU%d updated upon resume\n", cpu);
-
-	return UCODE_OK;
-}
-
-static enum ucode_state microcode_init_cpu(int cpu, bool refresh_fw)
-{
-	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-	enum ucode_state ustate;
-
-	if (uci->valid)
-		return UCODE_OK;
-
-	if (collect_cpu_info(cpu))
-		return UCODE_ERROR;
-
-	/* --dimm. Trigger a delayed update? */
-	if (system_state != SYSTEM_RUNNING)
-		return UCODE_NFOUND;
-
-	ustate = microcode_ops->request_microcode_fw(cpu, &microcode_pdev->dev, refresh_fw);
-	if (ustate == UCODE_NEW) {
-		pr_debug("CPU%d updated upon init\n", cpu);
-		apply_microcode_on_target(cpu);
-	}
-
-	return ustate;
-}
-
-static enum ucode_state microcode_update_cpu(int cpu)
+static enum ucode_state microcode_init_cpu(int cpu)
 {
 	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
 
-	/* Refresh CPU microcode revision after resume. */
-	collect_cpu_info(cpu);
+	memset(uci, 0, sizeof(*uci));
 
-	if (uci->valid)
-		return microcode_resume_cpu(cpu);
+	microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
 
-	return microcode_init_cpu(cpu, false);
+	return microcode_ops->apply_microcode(cpu);
 }
 
 /**
@@ -651,14 +561,14 @@ void microcode_bsp_resume(void)
 }
 
 static struct syscore_ops mc_syscore_ops = {
-	.resume			= microcode_bsp_resume,
+	.resume	= microcode_bsp_resume,
 };
 
 static int mc_cpu_starting(unsigned int cpu)
 {
-	microcode_update_cpu(cpu);
-	pr_debug("CPU%d added\n", cpu);
-	return 0;
+	enum ucode_state err = microcode_ops->apply_microcode(cpu);
+
+	return err == UCODE_ERROR;
 }
 
 static int mc_cpu_online(unsigned int cpu)
@@ -688,11 +598,13 @@ static int mc_cpu_down_prep(unsigned int cpu)
 static void setup_online_cpu(void *info)
 {
 	int cpu = smp_processor_id();
-	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-
-	memset(uci, 0, sizeof(*uci));
+	enum ucode_state err;
 
-	microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
+	err = microcode_init_cpu(cpu);
+	if (err == UCODE_ERROR) {
+		pr_err("Error applying microcode on CPU%d\n", cpu);
+		return;
+	}
 
 	mc_cpu_online(cpu);
 }
@@ -740,6 +652,13 @@ static int __init microcode_init(void)
 		goto out_pdev;
 	}
 
+	/*
+	 * Try to load microcode once on the BSP in case the initrd has older revision.
+	 *  Frankly, I have no clue how that can happen but hey, loading here is cheap so
+	 * why not.
+	 */
+	microcode_ops->request_microcode_fw(boot_cpu_data.cpu_index, &microcode_pdev->dev, true);
+
 	/* Do per-CPU setup */
 	cpus_read_lock();
 	on_each_cpu(setup_online_cpu, NULL, 0);
-- 
2.35.1


  reply	other threads:[~2022-10-19 17:54 UTC|newest]

Thread overview: 37+ 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       ` Borislav Petkov [this message]
2022-10-19 19:22         ` [PATCH 2/5] x86/microcode: Simplify init path even more 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 ` [PATCH 03/13] x86/microcode/intel: Fix a hang if early loading microcode fails Ashok Raj
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
  -- strict thread matches above, loose matches on Subject: below --
2022-10-28 14:26 [PATCH 0/5] x86/microcode: Clean up the init path Borislav Petkov
2022-10-28 14:26 ` [PATCH 2/5] x86/microcode: Simplify init path even more Borislav Petkov

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=20221019175426.31025-2-bp@alien8.de \
    --to=bp@alien8.de \
    --cc=arjan.van.de.ven@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --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