[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250211194407.2577252-9-sohil.mehta@intel.com>
Date: Tue, 11 Feb 2025 19:43:58 +0000
From: Sohil Mehta <sohil.mehta@...el.com>
To: x86@...nel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Fenghua Yu <fenghua.yu@...el.com>,
Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Zhang Rui <rui.zhang@...el.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
David Laight <david.laight.linux@...il.com>,
Sohil Mehta <sohil.mehta@...el.com>,
linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org,
linux-pm@...r.kernel.org,
linux-hwmon@...r.kernel.org
Subject: [PATCH v2 08/17] x86/microcode: Update the Intel processor flag scan check
The Family model check to read the processor flag MSR is misleading and
potentially incorrect. It doesn't consider Family while comparing the
model number. The original check did have a Family number but it got
lost/moved during refactoring.
intel_collect_cpu_info() is called through multiple paths such as early
initialization, CPU hotplug as well as IFS image load. Some of these
flows would be error prone due to the ambiguous check.
Correct the processor flag scan check to use a Family number and update
it to a VFM based one to make it more readable.
Signed-off-by: Sohil Mehta <sohil.mehta@...el.com>
---
v2: Use a VFM check instead of hardcoded numbers.
I evaluted whether CPUID can be avoided in intel_collect_cpu_info(). But
the answer seems a bit more complex than I expected.
* On the BSP, intel_collect_cpu_info() can be called very early
via load_ucode_bsp() even before cpu_data[] has been populated.
* In the hotplug path, based on section II.c. of
Documentation/power/suspend-and-cpuhotplug.rst rescanning of FMS
during ucode load might be intentional.
Maybe this can be resolved by updating the Intel ucode load flows to
pass the CPU information or the cpuid_eax information around. But it is
beyond the scope of this series. Also, I am not sure whether the
effort/risk would be worth saving a single cpuid() call in an uncommon
path. If this is desired, I can work on it in a seperate patch.
---
arch/x86/include/asm/intel-family.h | 1 +
arch/x86/kernel/cpu/microcode/intel.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 6d7b04ffc5fd..cccc932d761e 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -46,6 +46,7 @@
#define INTEL_ANY IFM(X86_FAMILY_ANY, X86_MODEL_ANY)
#define INTEL_PENTIUM_PRO IFM(6, 0x01)
+#define INTEL_PENTIUM_III_DESCHUTES IFM(6, 0x05)
#define INTEL_CORE_YONAH IFM(6, 0x0E)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index f3d534807d91..819199bc0119 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -74,7 +74,7 @@ void intel_collect_cpu_info(struct cpu_signature *sig)
sig->pf = 0;
sig->rev = intel_get_microcode_revision();
- if (x86_model(sig->sig) >= 5 || x86_family(sig->sig) > 6) {
+ if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) {
unsigned int val[2];
/* get processor flags from MSR 0x17 */
--
2.43.0
Powered by blists - more mailing lists