Over the past few months there’s been an in-progress patch series by Arnd Bergmann for cleaning up the x86 32-bit kernel support for running on x86_64 CPUs. After the third iteration of the patches were posted this week, these x86 32-bit CPU clean-ups were shuffled into the tip/tip.git “x86/cpu” Git branch ahead of the upcoming Linux 6.15 merge window.
Arnd Bergmann explains of the motivation and focus on the x86 32-bit CPU clean-up patch series:
“While looking at 32-bit arm cleanups, I came across some related topics on x86 and ended up making a series for those as well.
Primarily this is about running 32-bit kernels on 64-bit hardware, which usually works but should probably be discouraged more clearly by only providing support for features that are used on real 32-bit hardware:
I found only a few 2003-era high-end servers (HP DL740 and DL760 G2) that were the only possible remaining uses of HIGHMEM64G and BIGSMP after the removal of 32-bit NUMA machines in 2014. Similarly, there is only one generation of hardware with support for VT-x. All these features can be removed without hurting users.
In the CPU selection, building a 32-bit kernel optimized for AMD K8 or Intel Core2 is anachronistic, so instead only 32-bit CPU types need to be offered as optimization targets. The “generic” target on 64-bit turned out to be slightly broken, so I included a fix for that as well.”
In the new v3 patches, a patch is added to gate the EISA bus support so that it can only be enabled on x86 32-bit and not x86_64 kernels where EISA support isn’t relevant at all. Plus a few other changes in the patch series.
This patch adds the CMPXCHG64 instruction to the Kconfig for the Geode LX CPU configuration, drops 32-bit “BIGSMP” machine support for handling more than 8 CPUs within 32-bit kernels, dropping HIGHMEM4G support for x86 32-bit CPUs to use more than 4GB of physical memory (64GB allowed with this former option), dropping CONFIG_HIGHPTE since the 32-bit kernels will now max out at 4GB of RAM, and dropping support for the ST ConneXt STA2x11 as an interface chip for Atom E6xx processors.
As for dropping the HIGHMEM64G support for allowing more than 4GB of RAM on x86 32-bit kernels, Arnd argues in the patch:
“HIGHMEM64G support was added in linux-2.3.25 to support (then) high-end Pentium Pro and Pentium III Xeon servers with more than 4GB of addressing, NUMA and PCI-X slots started appearing.
I have found no evidence of this ever being used in regular dual-socket servers or consumer devices, all the users seem obsolete these days, even by i386 standards:
– Support for NUMA servers (NUMA-Q, IBM x440, unisys) was already removed ten years ago.
– 4+ socket non-NUMA servers based on Intel 450GX/450NX, HP F8 and ServerWorks ServerSet/GrandChampion could theoretically still work with 8GB, but these were exceptionally rare even 20 years ago and would have usually been equipped with than the maximum amount of RAM.
– Some SKUs of the Celeron D from 2004 had 64-bit mode fused off but could still work in a Socket 775 mainboard designed for the later Core 2 Duo and 8GB. Apparently most BIOSes at the time only allowed 64-bit CPUs.
– The rare Xeon LV “Sossaman” came on a few motherboards with registered DDR2 memory support up to 16GB.
– In the early days of x86-64 hardware, there was sometimes the need to run a 32-bit kernel to work around bugs in the hardware drivers, or in the syscall emulation for 32-bit userspace. This likely still works but there should never be a need for this any more.
PAE mode is still required to get access to the ‘NX’ bit on Atom ‘Pentium M’ and ‘Core Duo’ CPUs.”
I still have one of those “rare” Xeon LV Sossaman systems albeit it’s been at least a decade or more since I fired it up… Was fun back in the early days of Phoronix but not sad seeing this HIGHMEM64G / 32-bit PAE support retire.
These patches as of this morning have been queued up within tip/tip.git’s x86/cpu branch and thus likely material for submitting with the Linux 6.15 merge window. Linux 6.15 development should open up in late March following the v6.14 kernel debut.
