microcode_check() is only called from microcode/core.c. Move it and make
it static to prepare for upcoming fix of false negative when checking CPU
features after a microcode update. Also move get_cpu_cap() to processor.h
for general use outside of kernel/cpu.h
No functional change.
Suggested-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
Tony
Add movement of get_cpu_cap() to commit log
Reinette
Avoid including ../cpu.h and move to more general header.
Alison
Split patch to just move the function before use inside microcode
files.
---
arch/x86/include/asm/processor.h | 3 +--
arch/x86/kernel/cpu/cpu.h | 1 -
arch/x86/kernel/cpu/common.c | 32 ----------------------------
arch/x86/kernel/cpu/microcode/core.c | 31 +++++++++++++++++++++++++++
4 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 67c9d73b31fa..f5380806f3fa 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -192,8 +192,8 @@ extern const struct seq_operations cpuinfo_op;
#define cache_line_size() (boot_cpu_data.x86_cache_alignment)
+extern void get_cpu_cap(struct cpuinfo_x86 *c);
extern void cpu_detect(struct cpuinfo_x86 *c);
-
static inline unsigned long long l1tf_pfn_limit(void)
{
return BIT_ULL(boot_cpu_data.x86_cache_bits - 1 - PAGE_SHIFT);
@@ -835,7 +835,6 @@ bool xen_set_default_idle(void);
#endif
void __noreturn stop_this_cpu(void *dummy);
-void microcode_check(void);
enum l1tf_mitigations {
L1TF_MITIGATION_OFF,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 7c9b5893c30a..a142b8d543a3 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -63,7 +63,6 @@ static inline void tsx_ap_init(void) { }
extern void init_spectral_chicken(struct cpuinfo_x86 *c);
-extern void get_cpu_cap(struct cpuinfo_x86 *c);
extern void get_cpu_address_sizes(struct cpuinfo_x86 *c);
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 3e508f239098..bbd362ead043 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2305,38 +2305,6 @@ void cpu_init_secondary(void)
}
#endif
-#ifdef CONFIG_MICROCODE_LATE_LOADING
-/*
- * The microcode loader calls this upon late microcode load to recheck features,
- * only when microcode has been updated. Caller holds microcode_mutex and CPU
- * hotplug lock.
- */
-void microcode_check(void)
-{
- struct cpuinfo_x86 info;
-
- perf_check_microcode();
-
- /* Reload CPUID max function as it might've changed. */
- info.cpuid_level = cpuid_eax(0);
-
- /*
- * Copy all capability leafs to pick up the synthetic ones so that
- * memcmp() below doesn't fail on that. The ones coming from CPUID will
- * get overwritten in get_cpu_cap().
- */
- memcpy(&info.x86_capability, &boot_cpu_data.x86_capability, sizeof(info.x86_capability));
-
- get_cpu_cap(&info);
-
- if (!memcmp(&info.x86_capability, &boot_cpu_data.x86_capability, sizeof(info.x86_capability)))
- return;
-
- pr_warn("x86/CPU: CPU features have changed after loading microcode, but might not take effect.\n");
- pr_warn("x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
-}
-#endif
-
/*
* Invoked from core CPU hotplug code after hotplug operations
*/
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 712aafff96e0..ef24e1d228d0 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -431,6 +431,37 @@ static int __reload_late(void *info)
return ret;
}
+/*
+ * The microcode loader calls this upon late microcode load to recheck features,
+ * only when microcode has been updated. Caller holds microcode_mutex and CPU
+ * hotplug lock.
+ */
+static void microcode_check(void)
+{
+ struct cpuinfo_x86 info;
+
+ perf_check_microcode();
+
+ /* Reload CPUID max function as it might've changed. */
+ info.cpuid_level = cpuid_eax(0);
+
+ /*
+ * Copy all capability leafs to pick up the synthetic ones so that
+ * memcmp() below doesn't fail on that. The ones coming from CPUID will
+ * get overwritten in get_cpu_cap().
+ */
+ memcpy(&info.x86_capability, &boot_cpu_data.x86_capability, sizeof(info.x86_capability));
+
+ get_cpu_cap(&info);
+
+ if (!memcmp(&info.x86_capability, &boot_cpu_data.x86_capability,
+ sizeof(info.x86_capability)))
+ return;
+
+ pr_warn("x86/CPU: CPU features have changed after loading microcode, but might not take effect.\n");
+ pr_warn("x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
+}
+
/*
* Reload microcode late on all CPUs. Wait for a sec until they
* all gather together.
--
2.34.1On Tue, Nov 29, 2022 at 01:08:28PM -0800, Ashok Raj wrote:
> microcode_check() is only called from microcode/core.c. Move it and make
> it static to prepare for upcoming fix of false negative when checking CPU
> features after a microcode update.
So this function is there in cpu/common.c because it uses CPU facilities
like cpuinfo_x86 and get_cpu_cap() so the logical place was there.
So that I don't have to export a bunch of things but rather have the
microcode loader call into it only.
Your next patch is using more of those CPU-specific facilities so
"bleeding" them into the microcode loader looks like the wrong way
around.
get_cpu_cap() deals with all those c->x86_capability arrays and other
functions which do that, should be there too.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Dec 05, 2022 at 05:25:17PM +0100, Borislav Petkov wrote: > On Tue, Nov 29, 2022 at 01:08:28PM -0800, Ashok Raj wrote: > > microcode_check() is only called from microcode/core.c. Move it and make > > it static to prepare for upcoming fix of false negative when checking CPU > > features after a microcode update. > > So this function is there in cpu/common.c because it uses CPU facilities > like cpuinfo_x86 and get_cpu_cap() so the logical place was there. > So that I don't have to export a bunch of things but rather have the > microcode loader call into it only. > > Your next patch is using more of those CPU-specific facilities so > "bleeding" them into the microcode loader looks like the wrong way > around. > > get_cpu_cap() deals with all those c->x86_capability arrays and other > functions which do that, should be there too. I was trying to move this similar to how x86_read_arch_cap_msr() moved from x86/kernel/cpu/cpu.h -> asm/cpu.h. Keeping the usage local since there is just one caller to microcode_check() but there are other users of get_cpu_cap() like in arch/x86/xen/enlighten_pv.c which seems to be reaching out to ../kernel/cpu/cpu.h. That said, what you say also makes sense. I'm fine with what you decide how this should look. Cheers Ashok
On Mon, Dec 05, 2022 at 09:05:54AM -0800, Ashok Raj wrote:
> I was trying to move this similar to how x86_read_arch_cap_msr()
> moved from x86/kernel/cpu/cpu.h -> asm/cpu.h.
But that is only a function prototype - not the *actual* function.
> Keeping the usage local since there is just one caller to microcode_check()
> but there are other users of get_cpu_cap() like in
> arch/x86/xen/enlighten_pv.c which seems to be reaching out to
> ../kernel/cpu/cpu.h.
Yah, that's the single use outside of kernel/cpu/. Looks like a hack to me. :)
But no worries, we will clean all that up sooner or later and
get_cpu_cap() will disappear someday soon hopefully.
> That said, what you say also makes sense. I'm fine with what you decide how
> this should look.
Yes pls.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 11/29/2022 1:08 PM, Ashok Raj wrote: > microcode_check() is only called from microcode/core.c. Move it and make > it static to prepare for upcoming fix of false negative when checking CPU > features after a microcode update. Should we use this opportunity to also make the function name a bit more descriptive? microcode_check() seems very ambiguous to a first time reader. > +/* > + * The microcode loader calls this upon late microcode load to recheck features, > + * only when microcode has been updated. Caller holds microcode_mutex and CPU > + * hotplug lock. > + */ > +static void microcode_check(void) How about, microcode_recheck_features() or simply recheck_features() since it is static now? Sohil
On Fri, Dec 02, 2022 at 12:57:23PM -0800, Mehta, Sohil wrote: > On 11/29/2022 1:08 PM, Ashok Raj wrote: > > microcode_check() is only called from microcode/core.c. Move it and make > > it static to prepare for upcoming fix of false negative when checking CPU > > features after a microcode update. > > Should we use this opportunity to also make the function name a bit more > descriptive? microcode_check() seems very ambiguous to a first time reader. > > > +/* > > + * The microcode loader calls this upon late microcode load to recheck features, > > + * only when microcode has been updated. Caller holds microcode_mutex and CPU > > + * hotplug lock. > > + */ > > +static void microcode_check(void) > > How about, microcode_recheck_features() or simply recheck_features() since > it is static now? I suppose we could. But given that the function already has some comments around it and its not having multiple call sites, it seems to be reasonably serving its named purpose :-) Cheers, Ashok
On Tue, Nov 29 2022 at 13:08, Ashok Raj wrote: > microcode_check() is only called from microcode/core.c. Move it and make > it static to prepare for upcoming fix of false negative when checking CPU > features after a microcode update. Also move get_cpu_cap() to processor.h > for general use outside of kernel/cpu.h > > No functional change. > > Suggested-by: Alison Schofield <alison.schofield@intel.com> > Signed-off-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
© 2016 - 2025 Red Hat, Inc.