Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support

[phoronix]

Phoronix: Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support

The upcoming Linux 5.7 kernel is preparing to bid farewell to KVM virtualization support on 32-bit ARM architectures...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Kill-32-bit-ARM-KVM

[Raka555]

In any recent times, the 32-bit ARM KVM support perhaps was only used by anyone tinkering with it on an aging ARM SBC but without any serious use-case for 32-bit ARM KVM.

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

[rene]

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

yeah really annoying, why not leave users of old ARM machines this features, e.g. for testing, Qemu emulators, ... IMHO an modern OS should also be more fine grained modular, e.g. micro kernel to have all those features outside of the main kernel anyway: https://www.youtube.com/watch?v=EmQEE3cDxEo

[andyprough]

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

Any serious tinkerer worth their salt would just write their own kernel, compiler, and development environment. And fork systemd and Gnome to run on it so they could have homed and parental controls.

[Terrablit]

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

yeah really annoying, why not leave users of old ARM machines this features, e.g. for testing, Qemu emulators, ... IMHO an modern OS should also be more fine grained modular, e.g. micro kernel to have all those features outside of the main kernel anyway: https://www.youtube.com/watch?v=EmQEE3cDxEo

I'd like to have the feature in there, too. I've got a ton of 32-bit ARM devices hanging around. Features are great. Some even have enough RAM to actually be able to run a small VM. Problem is, who's going to maintain KVM support for it? Maintaining virtualization isn't easy. Realistically speaking, very few people use the feature. I guess there's some consumer NAS devices that *could* use it, but those companies aren't stepping forward. Most would rather you buy the more expensive x86 hardware if you're going to attempt virtualization. Same with the RPi foundation. The first two RPi generations were 32-bit.

Honestly, with those types of memory constraints, containers make more sense than VMs in the first place. Despite the feature being there, there's no consumer/prosumer VM images for ARM. Nobody's built the kind of images that would run and are useful. Most of it is for developers, and most who are developing on ARM either use the hardware they need, or they use qemu on a desktop.

It's also worth mentioning that containers on ARM weren't that big until last April when ARM and Docker started a partnership to push multi-architecture builds. Until then you had to roll your own. Which in most cases just wasn't worth the effort for most people. And I think it's still being built for 64-bit hardware.

It's a shame 32-bit ARM support didn't start getting good until people started wanting more out of their systems. But at least we caught the tail end of it thanks to corporate sponsors. And the good news is most affordable tinkerer devices for sale these days are 64-bit capable.

[Space Heater]

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

How is it "all just business" when developers want to remove a feature that is largely unused, and said feature is also impeding new development? I don't see how this is related to hobbyists vs. corporations, this is normal software engineering.

Also, when did they decide to maintain unused features just for the sake of tinkering in the past?

In the earlier days, the kernel developers were generally fine with breaking userspace and making radical internal changes, definitely not the conservative tinkerers you seem to imagine.

[NotMine999]

Any serious tinkerer worth their salt would just write their own kernel, compiler, and development environment. And fork systemd and Gnome to run on it so they could have homed and parental controls.

I see what you did there ... and I like it.

[starshipeleven]

yeah really annoying, why not leave users of old ARM machines this features,

because it will most likely break because of some other change and if no maintainer wants to fix it then it's worse as it's "ok" on paper but broken in practice. Been there with Mesa and (very) old radeon GPUs, and for the Xorg module for SiS graphics, among other things.

I'm sure you can also dig up some other examples on your own as you have an extensive collection of old hardware.

[starshipeleven]

"Once upon a time" linux was all about tinkering with stuff ...
Today it is all just business.

Just the way we like it.

[Space Heater]

Internal changes are fine; the kernel has no fixed internal or driver ABI. Userspace breakage is verboten...

Thanks for the condescending reply, but Linux's development model in the past did allow for userspace breakage.

e.g. devsfs, ipfwadm and ipchains are no more, and were user-facing.