| Message ID | 20250211194407.2577252-9-sohil.mehta@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Prepare for new Intel Family numbers | expand |
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 */
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@intel.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(-)