Re: [PATCH] x86: Unbreak early processor microcode loading

From: Daniel J Blueman
Date: Wed Mar 04 2015 - 03:27:31 EST


On 04/03/2015 00:38, Borislav Petkov wrote:
On Tue, Mar 03, 2015 at 11:10:44PM +0800, Daniel J Blueman wrote:
The changes in 871b72dd "x86: microcode: use smp_call_function_single instead
of set_cpus_allowed, cleanup of synchronization logic" introduced a check
that prevents built-in microcode from being loaded before init starts.

Conditionalise it on early microcode loading, so we get the expected behaviour
when early microcode loading is enabled, and when it is not. This has potential
importance as BIOSes often don't load the current microcode.

... probably because they don't have it. Which is also the main reason
for the existence of this microcode loader btw :)


Signed-off-by: Daniel J Blueman <daniel@xxxxxxxxxxxxx>
---
arch/x86/kernel/cpu/microcode/core.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 36a8361..fa7f9fc 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -391,9 +391,11 @@ static enum ucode_state microcode_init_cpu(int cpu, bool refresh_fw)
if (collect_cpu_info(cpu))
return UCODE_ERROR;

+#if !defined(CONFIG_MICROCODE_AMD_EARLY) && !defined(CONFIG_MICROCODE_INTEL_EARLY)
/* --dimm. Trigger a delayed update? */
if (system_state != SYSTEM_RUNNING)
return UCODE_NFOUND;
+#endif

Ok, let me try to understand this correctly: where is this microcode
built in, into the kernel?

If yes, you should consider enabling the early loading
method and build in the microcode into the initrd, see
Documentation/x86/early-microcode.txt

This is the preferred method as we're applying the microcode much
earlier.

Back to you.

Yes, it's built into the kernel with config:

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin"
CONFIG_EXTRA_FIRMWARE_DIR="../firmware"

That's as some customer and in-house environments we use are initramfs-less and some we don't have direct control over the initramfs.

I don't see why built-in microcode loading shouldn't work, so I guess the question is, why was that 'system_state .. RUNNING' check introduced?

If just a cleanup and loading built-in microcode early was overlooked, it may be reasonable to conditionalise the check like so.

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