lwn.git/arch/x86/kernel/cpu/microcode/intel.c, branch master

x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest

2026-05-26T20:36:23+00:00

Patch in Fixes: causes the usual: unchecked MSR access error: RDMSR from 0x17 at ... (intel_get_platform_id) Call Trace: early_init_intel early_cpu_init setup_arch _printk start_kernel x86_64_start_reservations x86_64_start_kernel common_startup_64 because the kernel is booted in a guest. In order to avoid it, this MSR access needs to be prevented when running virtualized. That is usually done by checking X86_FEATURE_HYPERVISOR but for this particular case it is too early yet. The platform ID needs to be read as early as when microcode is loaded on the BSP: load_ucode_bsp ... -> get_microcode_blob ... -> intel_find_matching_signature and by that time, CPUID leafs haven't been parsed yet. The microcode loader already has logic to check early whether the kernel is running virtualized so make that globally available to arch/x86/. The query whether running virtualized is getting more and more prominent in recent times so might as well make it an arch-global var which the rest of the code can use. Fixes: d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure") Reported-by: Vishal Verma Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Binbin Wu Reviewed-by: Xiaoyao Li Tested-by: Binbin Wu Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com

x86/cpu: Add platform ID to CPU info structure

2026-03-05T20:25:32+00:00

The end goal here is to be able to do x86_match_cpu() and match on a specific platform ID. While it would be possible to stash this ID off somewhere or read it dynamically, that approaches would not be consistent with the other fields which can be matched. Read the platform ID and store it in cpuinfo_x86. There are lots of sites to set this new field. Place it near the place c->microcode is established since the platform ID is so closely intertwined with microcode updates. Note: This should not grow the size of 'struct cpuinfo_x86' in practice since the u8 fits next to another u8 in the structure. Signed-off-by: Dave Hansen Reviewed-by: Sohil Mehta Reviewed-by: Pawan Gupta Link: https://patch.msgid.link/20260304181020.8D518228@davehans-spike.ostc.intel.com

x86/microcode: Refactor platform ID enumeration into a helper

2026-03-05T20:25:18+00:00

Today, the only code that cares about the platform ID is the microcode update code itself. To facilitate storing the platform ID in a more generic place and using it outside of the microcode update itself, put the enumeration into a helper function. Mirror intel_get_microcode_revision()'s naming and location. But, moving away from intel_collect_cpu_info() means that the model and family information in CPUID is not readily available. Just call CPUID again. Note that the microcode header is a mask of supported platform IDs. Only stick the ID part in the helper. Leave the 1<=PII, say <=PII. The PII is the real oddball here being the only CPU with Linux microcode updates but no platform ID. It's worth calling it out by name. This does subtly change the sig->pf for the PII though from 0x0 to 0x1. Make up for that by ignoring sig->pf when the microcode update platform mask is 0x0. [ dhansen: reflow comment for bpetkov ] Signed-off-by: Dave Hansen Reviewed-by: Sohil Mehta Reviewed-by: Pawan Gupta Link: https://patch.msgid.link/20260304181018.EB6404F8@davehans-spike.ostc.intel.com

x86/microcode/intel: Enable staging when available

2025-10-15T14:47:50+00:00

With staging support implemented, enable it when the CPU reports the feature. [ bp: Sort in the MSR properly. ] Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Chao Gao Reviewed-by: Tony Luck Tested-by: Anselm Busse Link: https://lore.kernel.org/20250320234104.8288-1-chang.seok.bae@intel.com

x86/microcode/intel: Support mailbox transfer

2025-10-15T14:47:43+00:00

The functions for sending microcode data and retrieving the next offset were previously placeholders, as they need to handle a specific mailbox format. While the kernel supports similar mailboxes, none of them are compatible with this one. Attempts to share code led to unnecessary complexity, so add a dedicated implementation instead. [ bp: Sort the include properly. ] Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Tested-by: Anselm Busse Link: https://lore.kernel.org/20250320234104.8288-1-chang.seok.bae@intel.com

x86/microcode/intel: Implement staging handler

2025-10-15T14:47:37+00:00

Previously, per-package staging invocations and their associated state data were established. The next step is to implement the actual staging handler according to the specified protocol. Below are key aspects to note: (a) Each staging process must begin by resetting the staging hardware. (b) The staging hardware processes up to a page-sized chunk of the microcode image per iteration, requiring software to submit data incrementally. (c) Once a data chunk is processed, the hardware responds with an offset in the image for the next chunk. (d) The offset may indicate completion or request retransmission of an already transferred chunk. As long as the total transferred data remains within the predefined limit (twice the image size), retransmissions should be acceptable. Incorporate them in the handler, while data transmission and mailbox format handling are implemented separately. [ bp: Sort the headers in a reversed name-length order. ] Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Tested-by: Anselm Busse Link: https://lore.kernel.org/20250320234104.8288-1-chang.seok.bae@intel.com

x86/microcode/intel: Define staging state struct

2025-10-15T14:47:31+00:00

Define a staging_state struct to simplify function prototypes by consolidating relevant data, instead of passing multiple local variables. Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Tested-by: Anselm Busse Link: https://lore.kernel.org/20250320234104.8288-1-chang.seok.bae@intel.com

x86/microcode/intel: Establish staging control logic

2025-10-15T14:47:20+00:00

When microcode staging is initiated, operations are carried out through an MMIO interface. Each package has a unique interface specified by the IA32_MCU_STAGING_MBOX_ADDR MSR, which maps to a set of 32-bit registers. Prepare staging with the following steps: 1. Ensure the microcode image is 32-bit aligned to match the MMIO register size. 2. Identify each MMIO interface based on its per-package scope. 3. Invoke the staging function for each identified interface, which will be implemented separately. [ bp: Improve error logging. ] Suggested-by: Thomas Gleixner Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Tested-by: Anselm Busse Link: https://lore.kernel.org/all/871pznq229.ffs@tglx

Merge branch 'x86/msr' into x86/core, to resolve conflicts

2025-05-13T08:42:06+00:00

Conflicts: arch/x86/boot/startup/sme.c arch/x86/coco/sev/core.c arch/x86/kernel/fpu/core.c arch/x86/kernel/fpu/xstate.c Semantic conflict: arch/x86/include/asm/sev-internal.h Signed-off-by: Ingo Molnar

x86/microcode: Consolidate the loader enablement checking

2025-05-05T08:51:00+00:00

Consolidate the whole logic which determines whether the microcode loader should be enabled or not into a single function and call it everywhere. Well, almost everywhere - not in mk_early_pgtbl_32() because there the kernel is running without paging enabled and checking dis_ucode_ldr et al would require physical addresses and uglification of the code. But since this is 32-bit, the easier thing to do is to simply map the initrd unconditionally especially since that mapping is getting removed later anyway by zap_early_initrd_mapping() and avoid the uglification. In doing so, address the issue of old 486er machines without CPUID support, not booting current kernels. [ mingo: Fix no previous prototype for ‘microcode_loader_disabled’ [-Wmissing-prototypes] ] Fixes: 4c585af7180c1 ("x86/boot/32: Temporarily map initrd for microcode loading") Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com