News: 0001510170

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

New Linux Patches Cleanup Code For Running x86 32-bit Kernels On x86_64 CPUs

([Linux Kernel] 5 Hours Ago x86 Kernels On x86_64 CPUs)


As we approach 2025, hopefully none of you are still running x86 32-bit kernels / 32-bit OS software on x86_64 processors, but should you still be into that, there are improvements on the way.

Running x86 32-bit kernels/software on x86_64 hardware hasn't been too popular since the netbook days with their limited RAM capacities... And thankfully most Linux distributions have begun phasing out their 32-bit kernel / OS image support and other 32-bit software needed aside from better compatibility when running a x86_64 distribution. But after recently working on 32-bit ARM clean-ups within the Linux kernel, longtime Linux developer Arnd Bergmann has taken to cleaning up the x86 32-bit kernel code used when running on x86_64 Intel/AMD processors.

Bergmann explained in the [1]x86: 32-bit cleanups patch series this morning:

"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. Similary, 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, replacing the compiler default target with an intentional selection between the useful levels."

The 11 patches add 185 new lines of code while stripping away 1,216 lines of code for those interested in x86 kernels on x86_64 hardware.

Notable among the patches is [2]ending 32-bit KVM host support on the basis of:

"There are very few 32-bit machines that support KVM, the main exceptions are the "Yonah" Generation Xeon-LV and Core Duo from 2006 and the Atom Z5xx "Silverthorne" from 2008 that were all release just before their 64-bit counterparts.

Using KVM as a host on a 64-bit CPU using a 32-bit kernel generally works fine, but is rather pointless since 64-bit kernels are much better supported and deal better with the memory requirements of VM guests.

Drop all the 32-bit-only portions and the "#ifdef CONFIG_X86_64" checks of the x86 KVM code and add a Kconfig dependency to only allow building this on 64-bit kernels.

Support for 32-bit guests is of course untouched by this."

Xeon LVs were fascinating back in the day (2006), but understandable in 2025 to be clearing out 32-bit KVM host support while retaining 32-bit guest OS compatibility.



[1] https://lore.kernel.org/lkml/20241204103042.1904639-1-arnd@kernel.org/

[2] https://lore.kernel.org/lkml/20241204103042.1904639-12-arnd@kernel.org/



gotar

uid313

jonkoops

FireBurn

kylew77

StarterX4

Hear me out. Linux is Microsoft's main competition right now. Because of
this we are forcing them to "innovate", something they would usually avoid.
Now if MS Bob has taught us anything, Microsoft is not a company that
should be innovating. When they do, they don't come up with things like
"better security" or "stability", they come back with "talking
paperclips", and "throw in every usless feature we can think of, memory
footprint be dammed".

Unfortunatly, they also come up with the bright idea of executing email.
Now MIME attachments aren't enough, they want you to be able to run/open
attachments right when you get them. This sounds like a good idea to
people who believe renaming directories to folders made computing possible
for the common man, but security wise it's like vigorously shaking a
package from the Unibomber.

So my friends, we are to blame. We pushed them into frantically trying to
invent "necessary" features to stay on top, and look where it got us. Many
of us are watching our beloved mail servers go down under the strain and
rebuilding our company's PC because of our pointless competition with MS.
I implore you to please drop Linux before Microsoft innovates again.

-- From a Slashdot.org post in regards to the ILOVEYOU email virus