kernel/arch/x86/Kconfig.cpu, branch linux-rolling-stable

x86/kbuild/64: Restrict clang versions that can use '-march=native'

2025-03-25T07:24:06Z

There are two issues that can appear when building with clang and '-march=native'. The first issue is a compiler crash in the ipv6 stack with clang-18, such as when building allmodconfig. This was frequently reported on the LLVM issue tracker: # Link: https://github.com/llvm/llvm-project/issues?q=is%3Aissue%20ip6_rcv_core Stack dump: 0. Program arguments: clang ... -march=native ... net/ipv6/ip6_input.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'net/ipv6/ip6_input.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@ip6_rcv_core' The second issue is certain -Wframe-larger-than warnings that appear with clang versions prior to 19, which introduced an optimization that produces much better code: # Link: https://github.com/llvm/llvm-project/commit/90ba33099cbb17e7c159e9ebc5a512037db99d6d [2] clang-18: drivers/media/pci/saa7164/saa7164-core.c:605:20: error: stack frame size (2392) exceeds limit (2048) in 'saa7164_irq' [-Werror,-Wframe-larger-than] 605 | static irqreturn_t saa7164_irq(int irq, void *dev_id) | ^ clang-19: drivers/media/pci/saa7164/saa7164-core.c:605:20: error: stack frame size (216) exceeds limit (128) in 'saa7164_irq' [-Werror,-Wframe-larger-than] 605 | static irqreturn_t saa7164_irq(int irq, void *dev_id) | ^ Restrict the testing of the availability of '-march=native' to all supported GCC versions and clang-19 and newer to avoid these known resolved issues. Fixes: 0480bc7e65dc ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Cc: Nick Desaulniers Cc: Tor Vic Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Kees Cook Cc: Josh Poimboeuf Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250324-x86-march-native-clang-19-and-newer-v1-1-3a05ed32a89e@kernel.org

x86/kbuild/64: Test for the availability of the -mtune=native compiler flag

2025-03-25T07:24:06Z

Stephen reported this build failure when cross-compiling: cc1: error: bad value 'native' for '-march=' switch Test for the availability of the -march=native flag. Reported-by: Stephen Rothwell Signed-off-by: Ingo Molnar Tested-by: Stephen Rothwell # build test Cc: Tor Vic Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Kees Cook Cc: Josh Poimboeuf Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250324172723.49fb0416@canb.auug.org.au

x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'

2025-03-25T07:24:06Z

Add a 'native' option that allows users to build an optimized kernel for their local machine (i.e. the machine which is used to build the kernel) by passing '-march=native' to CFLAGS. The idea comes from Linus' reply to Arnd's initial proposal: https://lore.kernel.org/all/CAHk-=wji1sV93yKbc==Z7OSSHBiDE=LAdG_d5Y-zPBrnSs0k2A@mail.gmail.com/ Here are some numbers comparing 'generic' to 'native' on a Skylake dual-core laptop (generic --> native): - vmlinux and compressed modules size: 125'907'744 bytes --> 125'595'280 bytes (-0.248 %) 18'810 kilobytes --> 18'770 kilobytes (-0.213 %) - phoronix, average of 3 runs: ffmpeg: 130.99 --> 131.15 (+0.122 %) nginx: 10'650 --> 10'725 (+0.704 %) hackbench (lower is better): 102.27 --> 99.50 (-2.709 %) - xz compression of firefox tarball (lower is better): 319.57 seconds --> 317.34 seconds (-0.698 %) - stress-ng, bogoops, average of 3 15-second runs: fork: 111'744 --> 115'509 (+3.397 %) bsearch: 7'211 --> 7'436 (+3.120 %) memfd: 3'591 --> 3'604 (+0.362 %) mmapfork: 630 --> 629 (-0.159 %) schedmix: 42'715 --> 43'251 (+1.255 %) epoll: 2'443'767 --> 2'454'413 (+0.436 %) vm: 1'442'256 --> 1'486'615 (+3.076 %) - schbench (two message threads), 30-second runs: 304 rps --> 305 rps (+0.329 %) There is little difference both in terms of size and of performance, however the native build comes out on top ever so slightly. [ mingo: Renamed the option to CONFIG_X86_NATIVE_CPU, expanded the help text and added Linus's Suggested-by tag. ] Suggested-by: Linus Torvalds Signed-off-by: Tor Vic Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Kees Cook Cc: Josh Poimboeuf Link: https://lore.kernel.org/r/20250321142859.13889-1-torvic9@mailbox.org

x86/mm: Add INVLPGB feature and Kconfig entry

2025-03-19T10:08:52Z

In addition, the CPU advertises the maximum number of pages that can be shot down with one INVLPGB instruction in CPUID. Save that information for later use. [ bp: use cpu_has(), typos, massage. ] Signed-off-by: Rik van Riel Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250226030129.530345-3-riel@surriel.com

x86/cpufeatures: Rename X86_CMPXCHG64 to X86_CX8

2025-02-28T10:42:34Z

Replace X86_CMPXCHG64 with X86_CX8, as CX8 is the name of the CPUID flag, thus to make it consistent with X86_FEATURE_CX8 defined in . No functional change intended. Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ingo Molnar Link: https://lore.kernel.org/r/20250228082338.73859-2-xin@zytor.com

x86/cpu: Drop configuration options for early 64-bit CPUs

2025-02-27T10:19:06Z

The x86 CPU selection menu is confusing for a number of reasons: When configuring 32-bit kernels, it shows a small number of early 64-bit microarchitectures (K8, Core 2) but not the regular generic 64-bit target that is the normal default. There is no longer a reason to run 32-bit kernels on production 64-bit systems, so only actual 32-bit CPUs need to be shown here. When configuring 64-bit kernels, the options also pointless as there is no way to pick any CPU from the past 15 years, leaving GENERIC_CPU as the only sensible choice. Address both of the above by removing the obsolete options and making all 64-bit kernels run on both Intel and AMD CPUs from any generation. Testing generic 32-bit kernels on 64-bit hardware remains possible, just not building a 32-bit kernel that requires a 64-bit CPU. Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250226213714.4040853-5-arnd@kernel.org

x86/Kconfig: Add cmpxchg8b support back to Geode CPUs

2025-02-27T10:19:05Z

An older cleanup of mine inadvertently removed geode-gx1 and geode-lx from the list of CPUs that are known to support a working cmpxchg8b. Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250226213714.4040853-2-arnd@kernel.org

x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6

2024-02-09T15:28:19Z

The kernel built with MCRUSOE is unbootable on Transmeta Crusoe. It shows the following error message: This kernel requires an i686 CPU, but only detected an i586 CPU. Unable to boot - please use a kernel appropriate for your CPU. Remove MCRUSOE from the condition introduced in commit in Fixes, effectively changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the CPU family given by CPUID. [ bp: Massage commit message. ] Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig") Signed-off-by: Aleksander Mazur Signed-off-by: Borislav Petkov (AMD) Acked-by: H. Peter Anvin Cc: Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl

x86/Kconfig: Rework CONFIG_X86_PAE dependency

2023-12-19T12:03:06Z

While looking at a Xen Kconfig dependency issue, I tried to understand the exact dependencies for CONFIG_X86_PAE, which is selected by CONFIG_HIGHMEM64G but can also be enabled manually. Apparently the dependencies for CONFIG_HIGHMEM64G are strictly about CPUs that do support PAE, but the actual feature can be incorrectly enabled on older CPUs as well. The CONFIG_X86_CMPXCHG64 dependencies on the other hand include X86_PAE because cmpxchg8b is requried for PAE to work. Rework this for readability and correctness, using a positive list of CPUs that support PAE in a new X86_HAVE_PAE symbol that can serve as a dependency for both X86_PAE and HIGHMEM64G as well as simplify the X86_CMPXCHG64 dependency list. Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231204084722.3789473-2-arnd@kernel.org

x86/cpu: Remove X86_FEATURE_NAMES

2023-05-15T18:03:08Z

While discussing to change the visibility of X86_FEATURE_NAMES (see Link) in order to remove CONFIG_EMBEDDED, Boris suggested to simply make the X86_FEATURE_NAMES functionality unconditional. As the need for really tiny kernel images has gone away and kernel images with !X86_FEATURE_NAMES are hardly tested, remove this config and the whole ifdeffery in the source code. Suggested-by: Borislav Petkov Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/all/20230509084007.24373-1-lukas.bulwahn@gmail.com/ Link: https://lore.kernel.org/r/20230510065713.10996-3-lukas.bulwahn@gmail.com