linux-stable.git/arch/x86/kernel/cpu/microcode/intel.c, branch linux-rolling-stable

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

x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'

2025-04-10T09:59:28+00:00

Suggested-by: "H. Peter Anvin" 
Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra (Intel) 
Cc: Juergen Gross 
Cc: Dave Hansen 
Cc: Xin Li 
Cc: Linus Torvalds

x86/microcode: Update the Intel processor flag scan check

2025-03-19T10:19:38+00:00

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 
Signed-off-by: Ingo Molnar 
Acked-by: Dave Hansen 
Link: https://lore.kernel.org/r/20250219184133.816753-4-sohil.mehta@intel.com

x86/microcode/intel: Remove unnecessary cache writeback and invalidation

2024-10-25T16:12:03+00:00

Currently, an unconditional cache flush is performed during every
microcode update. Although the original changelog did not mention
a specific erratum, this measure was primarily intended to address
a specific microcode bug, the load of which has already been blocked by
is_blacklisted(). Therefore, this cache flush is no longer necessary.

Additionally, the side effects of doing this have been overlooked. It
increases CPU rendezvous time during late loading, where the cache flush
takes between 1x to 3.5x longer than the actual microcode update.

Remove native_wbinvd() and update the erratum name to align with the
latest errata documentation, document ID 334163 Version 022US.

  [ bp: Zap the flaky documentation URL. ]

Fixes: 91df9fdf5149 ("x86/microcode/intel: Writeback and invalidate caches before updating microcode")
Reported-by: Yan Hua Wu 
Reported-by: William Xie 
Signed-off-by: Chang S. Bae 
Signed-off-by: Borislav Petkov (AMD) 
Acked-by: Ashok Raj 
Tested-by: Yan Hua Wu 
Link: https://lore.kernel.org/r/20241001161042.465584-2-chang.seok.bae@intel.com