Message-ID: <4E9F05F9.7080901@linux.vnet.ibm.com>
Date:	Wed, 19 Oct 2011 22:46:41 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Tejun Heo <tj@...nel.org>, "Rafael J. Wysocki" <rjw@...k.pl>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"tigran@...azian.fsnet.co.uk" <tigran@...azian.fsnet.co.uk>,
	"mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: [PATCH] CPU hotplug, x86 microcode: Revalidate microcode before microcode
 update

Hi,

Boris, you had mentioned that hpa's new ucode loading solution would
take care of hot-swap cases too.
I am referring to:
http://thread.gmane.org/gmane.linux.documentation/3414/focus=3454

However, since I am not aware of what hpa's new ucode loading solution
is, nor how it will handle this case, I thought of posting this patch
(now tested and fine-tuned), so that it can be applied in case this
patch is deemed to be necessary/desirable to avoid breaking hot-swap cases.

Thanks,
Srivatsa S. Bhat

---

This patch is intended to go with the patch posted at
http://thread.gmane.org/gmane.linux.kernel/1200882/focus=1200991

Since that patch optimizes microcode update by keeping the microcode image
in kernel memory and not freeing it up even when the CPU goes offline, it
means we would be applying the same microcode image when the CPU comes back
online.

However, if physically hotplugging of CPUs is supported, then we could
physically hot-unplug CPUs and then hot-plug new (and possibly a different
type of) CPUs. In such a case, it would be wrong to blindly apply the same
old microcode (that the kernel maintained for the old CPU) to this new CPU.

Hence, this patch adds a validation to check whether the microcode revision
we have in kernel memory and the revision that needs to be applied to the
CPU that was just brought online, are the same or not. If they happen to be
different, then it invalidates and frees the kernel's copy of the microcode,
triggering a fresh request to userspace to get the appropriate microcode
image for this CPU.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@...ux.vnet.ibm.com>
---

 arch/x86/kernel/microcode_core.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index f924280..1b353a3 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -155,6 +155,30 @@ static int collect_cpu_info(int cpu)
 	return ret;
 }
 
+/*
+ * Compare the microcode revision that the kernel has in memory
+ * for this cpu and the microcode revision that we need to apply
+ * on this cpu. If they match, return 0, else return -1.
+ */
+static int compare_cpu_with_microcode(int cpu)
+{
+	struct ucode_cpu_info *uci_mem = ucode_cpu_info + cpu;
+	struct ucode_cpu_info uci_cpu;
+	int ret;
+
+	memset(&uci_cpu, 0, sizeof(uci_cpu));
+
+	ret = collect_cpu_info_on_target(cpu, &uci_cpu.cpu_sig);
+	if (!ret) {
+		if (!(uci_mem->cpu_sig.sig == uci_cpu.cpu_sig.sig &&
+		      uci_mem->cpu_sig.pf == uci_cpu.cpu_sig.pf &&
+		      uci_mem->cpu_sig.rev == uci_cpu.cpu_sig.rev))
+			ret = -1;
+	}
+
+	return ret;
+}
+
 struct apply_microcode_ctx {
 	int err;
 };
@@ -397,6 +421,17 @@ static enum ucode_state microcode_update_cpu(int cpu)
 	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
 	enum ucode_state ustate;
 
+	/*
+	 * If the CPU on which we are going to update the
+	 * microcode and the microcode which we currently
+	 * have in kernel memory are incompatible, then
+	 * invalidate the microcode that we have (and also
+	 * free its memory), so that we can get the required
+	 * microcode afresh.
+	 */
+	if (compare_cpu_with_microcode(cpu))
+		microcode_fini_cpu(cpu);
+
 	if (uci->valid)
 		ustate = microcode_resume_cpu(cpu);
 	else


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists