Thomas Huth <th...@redhat.com> writes: > On 28/01/2025 01.42, Richard Henderson wrote: >> Time for our biennial attempt to kill ancient hosts. >> I've been re-working the tcg code generator a bit over the holidays. >> One place that screams for a bit of cleanup is with 64-bit guest >> addresses on 32-bit hosts. Of course the best "cleanup" is to not >> have to handle such silliness at all. >> Two years after Thomas' last attempt, >> >> https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-th...@redhat.com/ >> which resulted only in deprecation of i686 host for system >> emulation. >> By itself, this just isn't enough for large-scale cleanups. >> I'll note that we've separately deprecated mips32, set to expire >> with the end of Debian bookworm, set to enter LTS in June 2026. >> I'll note that there is *already* no Debian support for ppc32, >> and that I am currently unable to cross-compile that host at all. > > IIRC the biggest pushback that I got two years ago was with regards to > 32-bit arm: The recommended version of Raspberry Pi OS is still > 32-bit: > > > https://lore.kernel.org/qemu-devel/f852c238-77b8-4e24-9494-8d060eb78...@livius.net/ > > And looking at https://www.raspberrypi.com/software/operating-systems/ > this still seems to be the case... > > So I guess the main question is now: Would it be ok to kill support > for 32-bit Raspberry Pi OS nowadays?
I would argue yes for a few reasons. - you can't buy 32 bit only Pi's AFAICT, even the Pi Zero 2W can work with a 64 bit OS. - It's not like the versions shipping in bullseye and bookworm will stop working. - Even if we deprecate now there will likely be one more Debian release cycle that gets 32 bit host support. >> Showing my hand a bit, I am willing to limit deprecation to >> 64-bit guests on 32-bit hosts. But I'd prefer to go the whole hog: >> unconditional support for TCG_TYPE_I64 would remove a *lot* of >> 32-bit fallback code. I support going the whole hog. I would be curious what use cases still exist for an up to date 32-on-32 QEMU based emulation? > > Sound like a good alternative to me! > > Thomas -- Alex Bennée Virtualisation Tech Lead @ Linaro