On Dec 13, 2024, at 2:20 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >>>> From: Arnd Bergmann <arnd@xxxxxxxx> >>>> >>>> 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.
