[RFC 0/5] KVM: drop 32-bit host support on all architectures

[A. Wilcox]

On Dec 13, 2024, at 2:20 AM, Paolo Bonzini <pbonzini at redhat.com> wrote:
> 
> On 12/13/24 09:03, Arnd Bergmann wrote:
>> On Fri, Dec 13, 2024, at 04:51, A. Wilcox wrote:
>>> On Dec 12, 2024, at 6:55 AM, Arnd Bergmann <arnd at kernel.org> wrote:
>>>> From: Arnd Bergmann <arnd at arndb.de>
>>>> 
>>>> I submitted a patch to remove KVM support for x86-32 hosts earlier
>>>> this month, but there were still concerns that this might be useful for
>>>> testing 32-bit host in general, as that remains supported on three other
>>>> architectures. I have gone through those three now and prepared similar
>>>> patches, as all of them seem to be equally obsolete.
>>>> 
>>>> Support for 32-bit KVM host on Arm hardware was dropped back in 2020
>>>> because of lack of users, despite Cortex-A7/A15/A17 based SoCs being
>>>> much more widely deployed than the other virtualization capable 32-bit
>>>> CPUs (Intel Core Duo/Silverthorne, PowerPC e300/e500/e600, MIPS P5600)
>>>> combined.
>>> 
>>> 
>>> I do use 32-bit KVM on a Core Duo “Yonah” and a Power Mac G4 (MDD), for
>>> purposes of bisecting kernel issues without having to reboot the host
>>> machine (when it can be duplicated in a KVM environment).
>>> 
>>> I suppose it would still be possible to run the hosts on 6.12 LTS for
>>> some time with newer guests, but it would be unfortunate.
>> Would it be an option for you to just test those kernels on 64-bit
>> machines? I assume you prefer to do native builds on 32-bit hardware
>> because that fits your workflow, but once you get into debugging
>> in a virtual machine, the results should generally be the same when
>> building and running on a 64-bit host for both x86-32 and ppc32-classic,
>> right?
> 
> Certainly for x86-32; ppc32 should be able to use PR-state (aka
> trap and emulate) KVM on a 64-bit host but it's a bit more picky.
> Another possibility for ppc32 is just emulation with QEMU.
> 
> Paolo


Most of the reason I use KVM instead of emulation is because I don’t
trust QEMU emulation at all.  There was even a kernel bug that was
introduced affecting 32-bit x86 in the 4.0 cycle that only happened
because QEMU wasn’t emulating writes to %cr4 properly[1].  And PPC32
emulation is far worse than x86_32.  However, I probably could end
up doing x86_32 testing on a combination of bare metal machines and
KVM on x86_64, sure.

As for Power: I will admit I haven’t tested lately, but well into
the 5 series (5.4, at least), you couldn’t boot a ppc32 Linux kernel
on any 64-bit capable hardware.  It would throw what I believe was an
alignment error while quiescing OpenFirmware and toss you back to an
‘ok >’ prompt.  Unfortunately I can’t find any of the bug reports
or ML threads from the time - it was a known bug in the 2.6 days - but
the answer was always “why are you booting a ppc32 kernel on that
hardware anyway?  It’s a ppc64 machine!”  Is this a case where
that would be accepted as a legitimate bug now?  It would be lovely
to use my largely-SMT 3.0 GHz Power9 box for more of my kernel testing
(where possible) instead of relying on a 933 MHz single-thread G4.

-arw

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a833581e372a;
It had some form of security impact on Pentium-class machines, too,
as RDPMC became available to non-root even when /sys/devices/cpu/rdpmc
was 0.