From 9232c49ff31c40fa5cf72acf74c4aa251ed4811c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:43 +0100 Subject: [PATCH 01/16] x86/Kconfig: Enable X86_X2APIC by default and improve help text MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As many current platforms (most modern Intel CPUs and QEMU) have x2APIC present, enable CONFIG_X86_X2APIC by default as it gives performance and functionality benefits. Additionally, if the BIOS has already switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the kernel will panic in arch/x86/kernel/apic/apic.c . Also improve the help text, which was confusing and really did not describe what the feature is about. Help text references and discussion: Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic". "It allows faster access to the local APIC" [2], chapter 2.1, page 15: "More efficient MSR interface to access APIC registers." "x2APIC was introduced in Intel CPUs around 2008": I was unable to find specific information which Intel CPUs support x2APIC. Wikipedia claims it was "introduced with the Nehalem microarchitecture in November 2008", but I was not able to confirm this independently. At least some Nehalem CPUs do not support x2APIC [1]. The documentation [2] is dated June 2008. Linux kernel also introduced x2APIC support in 2008, so the year seems to be right. "and in AMD EPYC CPUs in 2019": [3], page 15: "AMD introduced an x2APIC in our EPYC 7002 Series processors for the first time." "It is also frequently emulated in virtual machines, even when the host CPU does not support it." [1] "If this configuration option is disabled, the kernel will not boot on some platforms that have x2APIC enabled." According to some BIOS documentation [4], the x2APIC may be "disabled", "enabled", or "force enabled" on this system. I think that "enabled" means "made available to the operating system, but not already turned on" and "force enabled" means "already switched to x2APIC mode when the OS boots". Only in the latter mode a kernel without CONFIG_X86_X2APIC will panic in validate_x2apic() in arch/x86/kernel/apic/apic.c . QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the "enabled" mode and the kernel does not panic. [1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup" https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html [2] Intel® 64 Architecture x2APIC Specification, ( https://www.naic.edu/~phil/software/intel/318148.pdf ) [3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based Servers Application Note, https://developer.amd.com/wp-content/resources/56745_0.80.pdf [4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant Gen10, ProLiant Gen10 Plus Servers and HPE Synergy: Enabling or disabling Processor x2APIC Support https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html Signed-off-by: Mateusz Jończyk Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-1-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 98bd4935280c..08bc939abc13 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -458,20 +458,27 @@ config SMP If you don't know what to do here, say N. config X86_X2APIC - bool "Support x2apic" + bool "x2APIC interrupt controller architecture support" depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST) + default y help - This enables x2apic support on CPUs that have this feature. + x2APIC is an interrupt controller architecture, a component of which + (the local APIC) is present in the CPU. It allows faster access to + the local APIC and supports a larger number of CPUs in the system + than the predecessors. - This allows 32-bit apic IDs (so it can support very large systems), - and accesses the local apic via MSRs not via mmio. + x2APIC was introduced in Intel CPUs around 2008 and in AMD EPYC CPUs + in 2019, but it can be disabled by the BIOS. It is also frequently + emulated in virtual machines, even when the host CPU does not support + it. Support in the CPU can be checked by executing + cat /proc/cpuinfo | grep x2apic - Some Intel systems circa 2022 and later are locked into x2APIC mode - and can not fall back to the legacy APIC modes if SGX or TDX are - enabled in the BIOS. They will boot with very reduced functionality - without enabling this option. + If this configuration option is disabled, the kernel will not boot on + some platforms that have x2APIC enabled. - If you don't know what to do here, say N. + Say N if you know that your platform does not have x2APIC. + + Otherwise, say Y. config X86_POSTED_MSI bool "Enable MSI and MSI-x delivery by posted interrupts" From 31be5041dca37a67c11042678c55804e964e5145 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:44 +0100 Subject: [PATCH 02/16] x86/Kconfig: Always enable ARCH_SPARSEMEM_ENABLE MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It appears that (X86_64 || X86_32) is always true on x86. This logical OR directive was introduced in: 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL") By (EXPERIMENTAL && X86_32) turning into (X86_32). Since this change was an identity transformation, nobody noticed that the condition turned into 'true'. [ mingo: Updated changelog ] Fixes: 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL") Signed-off-by: Mateusz Jończyk Signed-off-by: David Heideberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-2-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 08bc939abc13..442936d864c6 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1563,7 +1563,6 @@ config ARCH_FLATMEM_ENABLE config ARCH_SPARSEMEM_ENABLE def_bool y - depends on X86_64 || NUMA || X86_32 select SPARSEMEM_STATIC if X86_32 select SPARSEMEM_VMEMMAP_ENABLE if X86_64 From e35e328d37ee20df9a4dc9c4b0478f9e6b2c8c3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:45 +0100 Subject: [PATCH 03/16] x86/Kconfig: Move all X86_EXTENDED_PLATFORM options together MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit So that these options will be displayed together in menuconfig etc. Signed-off-by: Mateusz Jończyk Signed-off-by: David Heidelberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-3-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 442936d864c6..d6155b93fb8f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -665,6 +665,17 @@ config X86_INTEL_QUARK Say Y here if you have a Quark based system such as the Arduino compatible Intel Galileo. +config X86_RDC321X + bool "RDC R-321x SoC" + depends on X86_32 + depends on X86_EXTENDED_PLATFORM + select M486 + select X86_REBOOTFIXUPS + help + This option is needed for RDC R-321x system-on-chip, also known + as R-8610-(G). + If you don't have one of these chips, you should say N here. + config X86_INTEL_LPSS bool "Intel Low Power Subsystem Support" depends on X86 && ACPI && PCI @@ -718,17 +729,6 @@ config IOSF_MBI_DEBUG If you don't require the option or are in doubt, say N. -config X86_RDC321X - bool "RDC R-321x SoC" - depends on X86_32 - depends on X86_EXTENDED_PLATFORM - select M486 - select X86_REBOOTFIXUPS - help - This option is needed for RDC R-321x system-on-chip, also known - as R-8610-(G). - If you don't have one of these chips, you should say N here. - config X86_SUPPORTS_MEMORY_FAILURE def_bool y # MCE code calls memory_failure(): From 4047e8773fb627df3779291d9138e425537573af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:46 +0100 Subject: [PATCH 04/16] x86/Kconfig: Update lists in X86_EXTENDED_PLATFORM MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The order of the entries matches the order they appear in Kconfig. In 2011, AMD Elan was moved to Kconfig.cpu and the dependency on X86_EXTENDED_PLATFORM was dropped in: ce9c99af8d4b ("x86, cpu: Move AMD Elan Kconfig under "Processor family"") Support for Moorestown MID devices was removed in 2012 in: 1a8359e411eb ("x86/mid: Remove Intel Moorestown") SGI 320/540 (Visual Workstation) was removed in 2014 in: c5f9ee3d665a ("x86, platforms: Remove SGI Visual Workstation") Signed-off-by: Mateusz Jończyk Signed-off-by: David Heideberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-4-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d6155b93fb8f..917cd2f839f5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -542,16 +542,20 @@ config X86_EXTENDED_PLATFORM CONFIG_64BIT. 32-bit platforms (CONFIG_64BIT=n): - Goldfish (Android emulator) - AMD Elan + Goldfish (mostly Android emulator) + Intel CE media processor (CE4100) SoC + Intel MID (Mobile Internet Device) + Intel Quark RDC R-321x SoC - SGI 320/540 (Visual Workstation) + STA2X11-based (e.g. Northville) 64-bit platforms (CONFIG_64BIT=y): Numascale NumaChip ScaleMP vSMP SGI Ultraviolet Merrifield/Moorefield MID devices + Goldfish (mostly Android emulator) + Intel MID (Mobile Internet Device) If you have one of these systems, or if you want to build a generic distribution kernel, say Y here - otherwise say N. From 21d8fb8d4e7071b2e60bc48c217ff1b4ce8cb855 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:47 +0100 Subject: [PATCH 05/16] x86/Kconfig: Document CONFIG_PCI_MMCONFIG MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This configuration option had no help text, so add it. CONFIG_EXPERT is enabled on some distribution kernels, so people using a distribution kernel's configuration as a starting point will see this option. [ mingo: Standardized the new Kconfig text a bit. ] Signed-off-by: Mateusz Jończyk Signed-off-by: David Heideberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-5-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 917cd2f839f5..a079ecf15c71 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2902,6 +2902,19 @@ config PCI_MMCONFIG default y depends on PCI && (ACPI || JAILHOUSE_GUEST) depends on X86_64 || (PCI_GOANY || PCI_GOMMCONFIG) + help + Add support for accessing the PCI configuration space as a memory + mapped area. It is the recommended method if the system supports + this (it must have PCI Express and ACPI for it to be available). + + In the unlikely case that enabling this configuration option causes + problems, the mechanism can be switched off with the 'pci=nommconf' + command line parameter. + + Say N only if you are sure that your platform does not support this + access method or you have problems caused by it. + + Say Y otherwise. config PCI_OLPC def_bool y From d9f87802676bb23b9425aea8ad95c76ad9b50c6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:48 +0100 Subject: [PATCH 06/16] x86/Kconfig: Make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I was unable to find a good description of the ServerWorks CNB20LE chipset. However, it was probably exclusively used with the Pentium III processor (this CPU model was used in all references to it that I found where the CPU model was provided: dmesgs in [1] and [2]; [3] page 2; [4]-[7]). As is widely known, the Pentium III processor did not support the 64-bit mode, support for which was introduced by Intel a couple of years later. So it is safe to assume that no systems with the CNB20LE chipset have amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32. Additionally, I have determined that most computers with the CNB20LE chipset did have ACPI support and this driver was inactive on them. I have submitted a patch to remove this driver, but it was met with resistance [8]. [1] Jim Studt, Re: Problem with ServerWorks CNB20LE and lost interrupts Linux Kernel Mailing List, https://lkml.org/lkml/2002/1/11/111 [2] RedHat Bug 665109 - e100 problems on old Compaq Proliant DL320 https://bugzilla.redhat.com/show_bug.cgi?id=665109 [3] R. Hughes-Jones, S. Dallison, G. Fairey, Performance Measurements on Gigabit Ethernet NICs and Server Quality Motherboards, http://datatag.web.cern.ch/papers/pfldnet2003-rhj.doc [4] "Hardware for Linux", Probe #d6b5151873 of Intel STL2-bd A28808-302 Desktop Computer (STL2) https://linux-hardware.org/?probe=d6b5151873 [5] "Hardware for Linux", Probe #0b5d843f10 of Compaq ProLiant DL380 https://linux-hardware.org/?probe=0b5d843f10 [6] Ubuntu Forums, Dell Poweredge 2400 - Adaptec SCSI Bus AIC-7880 https://ubuntuforums.org/showthread.php?t=1689552 [7] Ira W. Snyder, "BISECTED: 2.6.35 (and -git) fail to boot: APIC problems" https://lkml.org/lkml/2010/8/13/220 [8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom CNB20LE PCI host bridge driver" https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/ Signed-off-by: Mateusz Jończyk Signed-off-by: David Heideberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-6-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a079ecf15c71..1090eda3c29f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2929,13 +2929,21 @@ config MMCONF_FAM10H depends on X86_64 && PCI_MMCONFIG && ACPI config PCI_CNB20LE_QUIRK - bool "Read CNB20LE Host Bridge Windows" if EXPERT - depends on PCI + bool "Read PCI host bridge windows from the CNB20LE chipset" if EXPERT + depends on X86_32 && PCI help Read the PCI windows out of the CNB20LE host bridge. This allows PCI hotplug to work on systems with the CNB20LE chipset which do not have ACPI. + The ServerWorks (later Broadcom) CNB20LE was a chipset designed + most probably only for Pentium III. + + To find out if you have such a chipset, search for a PCI device with + 1166:0009 PCI IDs, for example by executing + lspci -nn | grep '1166:0009' + The code is inactive if there is none. + There's no public spec for this chipset, and this functionality is known to be incomplete. From de7115636c41fd0c654f5865d513df52a0798f5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Fri, 21 Mar 2025 21:48:49 +0100 Subject: [PATCH 07/16] x86/Kconfig: Document release year of glibc 2.3.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I wonder how many people were checking their glibc version when considering whether to enable this option. Signed-off-by: Mateusz Jończyk Signed-off-by: David Heidelberg Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-7-b0cbaa6fa338@ixit.cz --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1090eda3c29f..e72cb7779038 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2213,7 +2213,7 @@ config HOTPLUG_CPU config COMPAT_VDSO def_bool n - prompt "Disable the 32-bit vDSO (needed for glibc 2.3.3)" + prompt "Workaround for glibc 2.3.2 / 2.3.3 (released in year 2003/2004)" depends on COMPAT_32 help Certain buggy versions of glibc will crash if they are From c8c81458863ab686cda4fe1e603fccaae0f12460 Mon Sep 17 00:00:00 2001 From: Pawan Gupta Date: Thu, 20 Mar 2025 11:13:15 -0700 Subject: [PATCH 08/16] x86/speculation: Remove the extra #ifdef around CALL_NOSPEC Commit: 010c4a461c1d ("x86/speculation: Simplify and make CALL_NOSPEC consistent") added an #ifdef CONFIG_MITIGATION_RETPOLINE around the CALL_NOSPEC definition. This is not required as this code is already under a larger #ifdef. Remove the extra #ifdef, no functional change. vmlinux size remains same before and after this change: CONFIG_MITIGATION_RETPOLINE=y: text data bss dec hex filename 25434752 7342290 2301212 35078254 217406e vmlinux.before 25434752 7342290 2301212 35078254 217406e vmlinux.after # CONFIG_MITIGATION_RETPOLINE is not set: text data bss dec hex filename 22943094 6214994 1550152 30708240 1d49210 vmlinux.before 22943094 6214994 1550152 30708240 1d49210 vmlinux.after Signed-off-by: Pawan Gupta Signed-off-by: Ingo Molnar Reviewed-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20250320-call-nospec-extra-ifdef-v1-1-d9b084d24820@linux.intel.com --- arch/x86/include/asm/nospec-branch.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index 804b66a7686a..29ea8fb16273 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -435,12 +435,8 @@ static inline void call_depth_return_thunk(void) {} * Inline asm uses the %V modifier which is only in newer GCC * which is ensured when CONFIG_MITIGATION_RETPOLINE is defined. */ -#ifdef CONFIG_MITIGATION_RETPOLINE #define CALL_NOSPEC __CS_PREFIX("%V[thunk_target]") \ "call __x86_indirect_thunk_%V[thunk_target]\n" -#else -#define CALL_NOSPEC "call *%[thunk_target]\n" -#endif # define THUNK_TARGET(addr) [thunk_target] "r" (addr) From 99bb1bd810eaf37e15ef757a30a815e774a2445b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Sat, 22 Mar 2025 16:45:41 +0100 Subject: [PATCH 09/16] x86/Kconfig: Correct X86_X2APIC help text MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, it is not true that the kernel will panic with CONFIG_X86_X2APIC=n on systems that require it; it will try to disable the APIC and run without it to at least give the user a clear warning message. See the second variant of check_x2apic() in arch/x86/kernel/apic/apic.c . Also massage some other parts of the help text. Fixes: 9232c49ff31c ("x86/Kconfig: Enable X86_X2APIC by default and improve help text") Signed-off-by: Mateusz Jończyk Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250322154541.40325-1-mat.jonczyk@o2.pl --- arch/x86/Kconfig | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index e72cb7779038..ef48584c8889 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -471,14 +471,15 @@ config X86_X2APIC in 2019, but it can be disabled by the BIOS. It is also frequently emulated in virtual machines, even when the host CPU does not support it. Support in the CPU can be checked by executing - cat /proc/cpuinfo | grep x2apic + grep x2apic /proc/cpuinfo - If this configuration option is disabled, the kernel will not boot on - some platforms that have x2APIC enabled. + If this configuration option is disabled, the kernel will boot with + very reduced functionality and performance on some platforms that + have x2APIC enabled. On the other hand, on hardware that does not + support x2APIC, a kernel with this option enabled will just fallback + to older APIC implementations. - Say N if you know that your platform does not have x2APIC. - - Otherwise, say Y. + If in doubt, say Y. config X86_POSTED_MSI bool "Enable MSI and MSI-x delivery by posted interrupts" From 2704ad556cf2b1f3a08526f4f12f9200cf7dcb03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= Date: Sat, 22 Mar 2025 18:50:52 +0100 Subject: [PATCH 10/16] x86/Kconfig: Fix lists in X86_EXTENDED_PLATFORM help text MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Support for STA2X11-based systems was removed in February in: dcbb01fbb7ae ("x86/pci: Remove old STA2x11 support") Intel MID for 32-bit platforms was removed from this list also in February in: ca5955dd5f08 ("x86/cpu: Document CONFIG_X86_INTEL_MID as 64-bit-only") Intel MID for 64-bit platforms is a duplicate for "Merrifield/Moorefield MID devices". Fixes: 4047e8773fb6 ("x86/Kconfig: Update lists in X86_EXTENDED_PLATFORM") Signed-off-by: Mateusz Jończyk Signed-off-by: Ingo Molnar Cc: Andy Shevchenko Link: https://lore.kernel.org/r/20250322175052.43611-1-mat.jonczyk@o2.pl --- arch/x86/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ef48584c8889..ce46252af1e5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -545,10 +545,8 @@ config X86_EXTENDED_PLATFORM 32-bit platforms (CONFIG_64BIT=n): Goldfish (mostly Android emulator) Intel CE media processor (CE4100) SoC - Intel MID (Mobile Internet Device) Intel Quark RDC R-321x SoC - STA2X11-based (e.g. Northville) 64-bit platforms (CONFIG_64BIT=y): Numascale NumaChip @@ -556,7 +554,6 @@ config X86_EXTENDED_PLATFORM SGI Ultraviolet Merrifield/Moorefield MID devices Goldfish (mostly Android emulator) - Intel MID (Mobile Internet Device) If you have one of these systems, or if you want to build a generic distribution kernel, say Y here - otherwise say N. From 57e2428f8df8263275344566e02c277648a4b7f1 Mon Sep 17 00:00:00 2001 From: Jann Horn Date: Tue, 25 Mar 2025 03:01:22 +0100 Subject: [PATCH 11/16] x86/entry: Fix ORC unwinder for PUSH_REGS with save_ret=1 PUSH_REGS with save_ret=1 is used by interrupt entry helper functions that initially start with a UNWIND_HINT_FUNC ORC state. However, save_ret=1 means that we clobber the helper function's return address (and then later restore the return address further down on the stack); after that point, the only thing on the stack we can unwind through is the IRET frame, so use UNWIND_HINT_IRET_REGS until we have a full pt_regs frame. ( An alternate approach would be to move the pt_regs->di overwrite down such that it is the final step of pt_regs setup; but I don't want to rearrange entry code just to make unwinding a tiny bit more elegant. ) Fixes: 9e809d15d6b6 ("x86/entry: Reduce the code footprint of the 'idtentry' macro") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Kees Cook Cc: Peter Zijlstra Cc: Josh Poimboeuf Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-1-acd774364768@google.com --- arch/x86/entry/calling.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index cb0911c5dc5d..d83236b96f22 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -70,6 +70,8 @@ For 32-bit we have the following conventions - kernel is built with pushq %rsi /* pt_regs->si */ movq 8(%rsp), %rsi /* temporarily store the return address in %rsi */ movq %rdi, 8(%rsp) /* pt_regs->di (overwriting original return address) */ + /* We just clobbered the return address - use the IRET frame for unwinding: */ + UNWIND_HINT_IRET_REGS offset=3*8 .else pushq %rdi /* pt_regs->di */ pushq %rsi /* pt_regs->si */ From 2c118f50d7fd4d9aefc4533a26f83338b2906b7a Mon Sep 17 00:00:00 2001 From: Jann Horn Date: Tue, 25 Mar 2025 03:01:23 +0100 Subject: [PATCH 12/16] x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment Commit: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header. This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places. Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines. Fix it by moving the "stack = " assignment back where it belongs. Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com --- arch/x86/kernel/dumpstack.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index 91639d1e4ec2..c6fefd4585f8 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -195,6 +195,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, printk("%sCall Trace:\n", log_lvl); unwind_start(&state, task, regs, stack); + stack = stack ?: get_stack_pointer(task, regs); regs = unwind_get_entry_regs(&state, &partial); /* @@ -213,9 +214,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, * - hardirq stack * - entry stack */ - for (stack = stack ?: get_stack_pointer(task, regs); - stack; - stack = stack_info.next_sp) { + for (; stack; stack = stack_info.next_sp) { const char *stack_name; stack = PTR_ALIGN(stack, sizeof(long)); From 3181424aeac2f6596534bf43021a10eae294a9b0 Mon Sep 17 00:00:00 2001 From: Denis Mukhin Date: Mon, 24 Mar 2025 17:55:40 -0700 Subject: [PATCH 13/16] x86/early_printk: Add support for MMIO-based UARTs During the bring-up of an x86 board, the kernel was crashing before reaching the platform's console driver because of a bug in the firmware, leaving no trace of the boot progress. The only available method to debug the kernel boot process was via the platform's MMIO-based UART, as the board lacked an I/O port-based UART, PCI UART, or functional video output. Then it turned out that earlyprintk= does not have a knob to configure the MMIO-mapped UART. Extend the early printk facility to support platform MMIO-based UARTs on x86 systems, enabling debugging during the system bring-up phase. The command line syntax to enable platform MMIO-based UART is: earlyprintk=mmio,membase[,{nocfg|baudrate}][,keep] Note, the change does not integrate MMIO-based UART support to: arch/x86/boot/early_serial_console.c Also, update kernel parameters documentation with the new syntax and add the missing 'nocfg' setting to the PCI serial cards description. Signed-off-by: Denis Mukhin Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250324-earlyprintk-v3-1-aee7421dc469@ford.com --- .../admin-guide/kernel-parameters.txt | 9 +++- arch/x86/kernel/early_printk.c | 45 ++++++++++++++++++- 2 files changed, 52 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 866427da6add..649261e97628 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1407,14 +1407,21 @@ earlyprintk=serial[,0x...[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] - earlyprintk=pciserial[,force],bus:device.function[,baudrate] + earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}] earlyprintk=xdbc[xhciController#] earlyprintk=bios + earlyprintk=mmio,membase[,{nocfg|baudrate}] earlyprintk is useful when the kernel crashes before the normal console is initialized. It is not enabled by default because it has some cosmetic problems. + Only 32-bit memory addresses are supported for "mmio" + and "pciserial" devices. + + Use "nocfg" to skip UART configuration, assume + BIOS/firmware has configured UART correctly. + Append ",keep" to not disable it when the real console takes over. diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c index fc1714bad045..611f27e3890c 100644 --- a/arch/x86/kernel/early_printk.c +++ b/arch/x86/kernel/early_printk.c @@ -190,7 +190,6 @@ static __init void early_serial_init(char *s) early_serial_hw_init(divisor); } -#ifdef CONFIG_PCI static __noendbr void mem32_serial_out(unsigned long addr, int offset, int value) { u32 __iomem *vaddr = (u32 __iomem *)addr; @@ -207,6 +206,45 @@ static __noendbr unsigned int mem32_serial_in(unsigned long addr, int offset) } ANNOTATE_NOENDBR_SYM(mem32_serial_in); +/* + * early_mmio_serial_init() - Initialize MMIO-based early serial console. + * @s: MMIO-based serial specification. + */ +static __init void early_mmio_serial_init(char *s) +{ + unsigned long baudrate; + unsigned long membase; + char *e; + + if (*s == ',') + s++; + + if (!strncmp(s, "0x", 2)) { + /* NB: only 32-bit addresses are supported. */ + membase = simple_strtoul(s, &e, 16); + early_serial_base = (unsigned long)early_ioremap(membase, PAGE_SIZE); + + static_call_update(serial_in, mem32_serial_in); + static_call_update(serial_out, mem32_serial_out); + + s += strcspn(s, ","); + if (*s == ',') + s++; + } + + if (!strncmp(s, "nocfg", 5)) { + baudrate = 0; + } else { + baudrate = simple_strtoul(s, &e, 0); + if (baudrate == 0 || s == e) + baudrate = DEFAULT_BAUD; + } + + if (baudrate) + early_serial_hw_init(115200 / baudrate); +} + +#ifdef CONFIG_PCI /* * early_pci_serial_init() * @@ -351,6 +389,11 @@ static int __init setup_early_printk(char *buf) keep = (strstr(buf, "keep") != NULL); while (*buf != '\0') { + if (!strncmp(buf, "mmio", 4)) { + early_mmio_serial_init(buf + 4); + early_console_register(&early_serial_console, keep); + buf += 4; + } if (!strncmp(buf, "serial", 6)) { buf += 6; early_serial_init(buf); From 878477a5953769d4fe5facc5033481f81d0dfce7 Mon Sep 17 00:00:00 2001 From: Chao Gao Date: Mon, 24 Mar 2025 21:19:27 +0800 Subject: [PATCH 14/16] x86/fpu: Update the outdated comment above fpstate_init_user() fpu_init_fpstate_user() was removed in: commit 582b01b6ab27 ("x86/fpu: Remove old KVM FPU interface"). Update that comment to accurately reflect the current state regarding its callers. Signed-off-by: Chao Gao Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250324131931.2097905-1-chao.gao@intel.com --- arch/x86/kernel/fpu/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 1b734a9ff088..91d6341f281f 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -508,7 +508,7 @@ static inline void fpstate_init_fstate(struct fpstate *fpstate) /* * Used in two places: * 1) Early boot to setup init_fpstate for non XSAVE systems - * 2) fpu_init_fpstate_user() which is invoked from KVM + * 2) fpu_alloc_guest_fpstate() which is invoked from KVM */ void fpstate_init_user(struct fpstate *fpstate) { From dc84bc2aba85a1508f04a936f9f9a15f64ebfb31 Mon Sep 17 00:00:00 2001 From: David Hildenbrand Date: Fri, 21 Mar 2025 12:23:23 +0100 Subject: [PATCH 15/16] x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab640379a0a ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee Reported-by: yuxin wang Reported-by: Marius Fleischer Signed-off-by: David Hildenbrand Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Rik van Riel Cc: "H. Peter Anvin" Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ --- arch/x86/mm/pat/memtype.c | 52 +++++++++++++++++++++------------------ include/linux/pgtable.h | 28 ++++++++++++++++----- kernel/fork.c | 4 +++ mm/memory.c | 11 +++------ 4 files changed, 58 insertions(+), 37 deletions(-) diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c index e40861c9cb90..72d8cbc61158 100644 --- a/arch/x86/mm/pat/memtype.c +++ b/arch/x86/mm/pat/memtype.c @@ -984,29 +984,42 @@ static int get_pat_info(struct vm_area_struct *vma, resource_size_t *paddr, return -EINVAL; } -/* - * track_pfn_copy is called when vma that is covering the pfnmap gets - * copied through copy_page_range(). - * - * If the vma has a linear pfn mapping for the entire range, we get the prot - * from pte and reserve the entire vma range with single reserve_pfn_range call. - */ -int track_pfn_copy(struct vm_area_struct *vma) +int track_pfn_copy(struct vm_area_struct *dst_vma, + struct vm_area_struct *src_vma, unsigned long *pfn) { + const unsigned long vma_size = src_vma->vm_end - src_vma->vm_start; resource_size_t paddr; - unsigned long vma_size = vma->vm_end - vma->vm_start; pgprot_t pgprot; + int rc; - if (vma->vm_flags & VM_PAT) { - if (get_pat_info(vma, &paddr, &pgprot)) - return -EINVAL; - /* reserve the whole chunk covered by vma. */ - return reserve_pfn_range(paddr, vma_size, &pgprot, 1); - } + if (!(src_vma->vm_flags & VM_PAT)) + return 0; + /* + * Duplicate the PAT information for the dst VMA based on the src + * VMA. + */ + if (get_pat_info(src_vma, &paddr, &pgprot)) + return -EINVAL; + rc = reserve_pfn_range(paddr, vma_size, &pgprot, 1); + if (rc) + return rc; + + /* Reservation for the destination VMA succeeded. */ + vm_flags_set(dst_vma, VM_PAT); + *pfn = PHYS_PFN(paddr); return 0; } +void untrack_pfn_copy(struct vm_area_struct *dst_vma, unsigned long pfn) +{ + untrack_pfn(dst_vma, pfn, dst_vma->vm_end - dst_vma->vm_start, true); + /* + * Reservation was freed, any copied page tables will get cleaned + * up later, but without getting PAT involved again. + */ +} + /* * prot is passed in as a parameter for the new mapping. If the vma has * a linear pfn mapping for the entire range, or no vma is provided, @@ -1095,15 +1108,6 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn, } } -/* - * untrack_pfn_clear is called if the following situation fits: - * - * 1) while mremapping a pfnmap for a new region, with the old vma after - * its pfnmap page table has been removed. The new vma has a new pfnmap - * to the same pfn & cache type with VM_PAT set. - * 2) while duplicating vm area, the new vma fails to copy the pgtable from - * old vma. - */ void untrack_pfn_clear(struct vm_area_struct *vma) { vm_flags_clear(vma, VM_PAT); diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 94d267d02372..4c107e17c547 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -1508,14 +1508,25 @@ static inline void track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot, } /* - * track_pfn_copy is called when vma that is covering the pfnmap gets - * copied through copy_page_range(). + * track_pfn_copy is called when a VM_PFNMAP VMA is about to get the page + * tables copied during copy_page_range(). On success, stores the pfn to be + * passed to untrack_pfn_copy(). */ -static inline int track_pfn_copy(struct vm_area_struct *vma) +static inline int track_pfn_copy(struct vm_area_struct *dst_vma, + struct vm_area_struct *src_vma, unsigned long *pfn) { return 0; } +/* + * untrack_pfn_copy is called when a VM_PFNMAP VMA failed to copy during + * copy_page_range(), but after track_pfn_copy() was already called. + */ +static inline void untrack_pfn_copy(struct vm_area_struct *dst_vma, + unsigned long pfn) +{ +} + /* * untrack_pfn is called while unmapping a pfnmap for a region. * untrack can be called for a specific region indicated by pfn and size or @@ -1528,8 +1539,10 @@ static inline void untrack_pfn(struct vm_area_struct *vma, } /* - * untrack_pfn_clear is called while mremapping a pfnmap for a new region - * or fails to copy pgtable during duplicate vm area. + * untrack_pfn_clear is called in the following cases on a VM_PFNMAP VMA: + * + * 1) During mremap() on the src VMA after the page tables were moved. + * 2) During fork() on the dst VMA, immediately after duplicating the src VMA. */ static inline void untrack_pfn_clear(struct vm_area_struct *vma) { @@ -1540,7 +1553,10 @@ extern int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot, unsigned long size); extern void track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot, pfn_t pfn); -extern int track_pfn_copy(struct vm_area_struct *vma); +extern int track_pfn_copy(struct vm_area_struct *dst_vma, + struct vm_area_struct *src_vma, unsigned long *pfn); +extern void untrack_pfn_copy(struct vm_area_struct *dst_vma, + unsigned long pfn); extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn, unsigned long size, bool mm_wr_locked); extern void untrack_pfn_clear(struct vm_area_struct *vma); diff --git a/kernel/fork.c b/kernel/fork.c index f11ac96b7587..91171e58541c 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -504,6 +504,10 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) vma_numab_state_init(new); dup_anon_vma_name(orig, new); + /* track_pfn_copy() will later take care of copying internal state. */ + if (unlikely(new->vm_flags & VM_PFNMAP)) + untrack_pfn_clear(new); + return new; } diff --git a/mm/memory.c b/mm/memory.c index 4f6d9766a046..53f7b0aaf2a3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1362,12 +1362,12 @@ int copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) { pgd_t *src_pgd, *dst_pgd; - unsigned long next; unsigned long addr = src_vma->vm_start; unsigned long end = src_vma->vm_end; struct mm_struct *dst_mm = dst_vma->vm_mm; struct mm_struct *src_mm = src_vma->vm_mm; struct mmu_notifier_range range; + unsigned long next, pfn; bool is_cow; int ret; @@ -1378,11 +1378,7 @@ copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) return copy_hugetlb_page_range(dst_mm, src_mm, dst_vma, src_vma); if (unlikely(src_vma->vm_flags & VM_PFNMAP)) { - /* - * We do not free on error cases below as remove_vma - * gets called on error from higher level routine - */ - ret = track_pfn_copy(src_vma); + ret = track_pfn_copy(dst_vma, src_vma, &pfn); if (ret) return ret; } @@ -1419,7 +1415,6 @@ copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) continue; if (unlikely(copy_p4d_range(dst_vma, src_vma, dst_pgd, src_pgd, addr, next))) { - untrack_pfn_clear(dst_vma); ret = -ENOMEM; break; } @@ -1429,6 +1424,8 @@ copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) raw_write_seqcount_end(&src_mm->write_protect_seq); mmu_notifier_invalidate_range_end(&range); } + if (ret && unlikely(src_vma->vm_flags & VM_PFNMAP)) + untrack_pfn_copy(dst_vma, pfn); return ret; } From 31ab12df723543047c3fc19cb8f8c4498ec6267f Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky Date: Thu, 27 Mar 2025 19:05:02 -0400 Subject: [PATCH 16/16] x86/microcode/AMD: Fix __apply_microcode_amd()'s return value When verify_sha256_digest() fails, __apply_microcode_amd() should propagate the failure by returning false (and not -1 which is promoted to true). Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Boris Ostrovsky Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250327230503.1850368-2-boris.ostrovsky@oracle.com --- arch/x86/kernel/cpu/microcode/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 138689b8e1d8..b61028cf5c8a 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -600,7 +600,7 @@ static bool __apply_microcode_amd(struct microcode_amd *mc, u32 *cur_rev, unsigned long p_addr = (unsigned long)&mc->hdr.data_code; if (!verify_sha256_digest(mc->hdr.patch_id, *cur_rev, (const u8 *)p_addr, psize)) - return -1; + return false; native_wrmsrl(MSR_AMD64_PATCH_LOADER, p_addr);