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 <[email protected]>
Signed-off-by: Ashok Raj <[email protected]>
---
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.1
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 <[email protected]>
> Signed-off-by: Ashok Raj <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
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 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