kernel/linux.git/arch/x86/Kconfig.cpu, branch linux-7.1.y

x86/cpu: Remove M486/M486SX/ELAN support

2026-03-30T09:39:42+00:00

In the x86 architecture we have various complicated hardware emulation facilities on x86-32 to support ancient 32-bit CPUs that very very few people are using with modern kernels. This compatibility glue is sometimes even causing problems that people spend time to resolve, which time could be spent on other things. As Linus recently remarked: > I really get the feeling that it's time to leave i486 support behind. > There's zero real reason for anybody to waste one second of > development effort on this kind of issue. Implement the first step and remove M486/M486SX/ELAN support: CONFIG_M486SX CONFIG_M486 CONFIG_MELAN [ There's no recent M486=y kernel package for any mainstream x86 32-bit distribution available that I've been able to find, so actual users should not be impacted, and any legacy users can keep using older kernels. ] Suggested-by: Linus Torvalds Signed-off-by: Ingo Molnar Reviewed-by: Arnd Bergmann Acked-by: Dave Hansen Cc: Ahmed S. Darwish Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: H. Peter Anvin Cc: John Ogness Link: https://patch.msgid.link/20251214084710.3606385-2-mingo@kernel.org

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

2025-03-25T07:24:06+00:00

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:06+00:00

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:06+00:00

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:52+00:00

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:34+00:00

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:06+00:00

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:05+00:00

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:19+00:00

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:06+00:00

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