Linux Developers Consider Ending 32-bit KVM Host Virtualization Support`

[phoronix]

Phoronix: Linux Developers Consider Ending 32-bit KVM Host Virtualization Support`

Earlier this month as part of patches for cleaning up x86 32-bit kernel code for x86_64 systems, there was a patch to drop support for 32-bit x86 KVM host support. That patch has now been split off into its own patch series with also now raising the prospects of ending 32-bit KVM host support across all CPU architectures rather than being just an x86-only change...

https://www.phoronix.com/news/Linux-Questions-32-bit-KVM-Host

[rmfx]

Good. Who would be using a 32 bit chip for kvm anyway? I would even remove 32 bit chips support from the entire kernel if I could.
“But the microcontrollers…” yes, 64 bit mandatory too.

[royce]

Delete scheibe

[andyprough]

This patch makes me want to drag out the ancient 32-bit Dell mini-tower from my parts closet and host a kvm virtual machine with it. Then I could email Bergman and say, "WAIT!! Wait! I haven't finished building 32-bit gentoo yet."

[--M--]

"Delete scheibe". That doesn't look like an adverb. Did you maybe want a noun? Then you must capitalize: "Delete Scheibe".

But why are you recommending to delete a (window) pane? Or did you refer to a (disk) platter?

Or did you misspell and meant "Delete Scheide". That's really misogynist and a bit vulgar.

Very puzzled what your comment is contributing, but then I I admit my idle speculation is not much better.

As for removing 32bit host support, I don't have a horse in the race. I don't have any need for it. Like most of us, I probably haven't used virtualization on 32 bit platforms in years. I do still need 32bit guest support on rare occasions though

[jeisom]

I don't know how much this hurts. It will still work with old releases and many people aren't going to run the latest and greatest on those systems anyway. The benefits of newer kernels on such old systems just isn't there. A lot of the optimizations are premised on thing like more ram and more cache, things that said systems often are lacking in.

Honestly I would not be surprised if at some point someone starts maintaining a kernel fork that focuses on just legacy hardware.

[duby229]

I don't know how much this hurts. It will still work with old releases and many people aren't going to run the latest and greatest on those systems anyway. The benefits of newer kernels on such old systems just isn't there. A lot of the optimizations are premised on thing like more ram and more cache, things that said systems often are lacking in.

Honestly I would not be surprised if at some point someone starts maintaining a kernel fork that focuses on just legacy hardware.

I don't know...

I've honestly had better luck using contemporary OSes to support old hardware, but the Internet hasn't been very good for data preservation so repositories and other online resources just don't exist anymore. On the other hand trying to build old kernels for old drivers with old dependencies on a modern OS is really difficult for the same reason.

Even Gentoo's Portage only keeps packages for a limited time. It would be gigantic, but I would love to have a portage repo with every version of every package going all the way back to 2004.... It doesn't exist, preservation just didn't happen....

[Espionage724]

Honestly I would not be surprised if at some point someone starts maintaining a kernel fork that focuses on just legacy hardware.

Old School Kernel, or Kernel: Classic; although I'd argue something has probably gone awry at some point if this actually becomes a feasible proposal

[MorrisS.]

Finally.

[bearoso]

I noticed while scanning that same patch set that they removed PAE support, too. So no more >4GB RAM on x86.