On 28/1/25 10:27, Daniel P. Berrangé wrote:
On Tue, Jan 28, 2025 at 10:17:33AM +0100, Philippe Mathieu-Daudé wrote:
On 28/1/25 10:02, Alex Bennée wrote:
Thomas Huth <thuth@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-
thuth@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-8D060EB78F9F@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?
Current maintainers don't have spare time to support the 32-on-32
emulation. If there is interest in the community for such niche,
someone needs to step forward, willing to maintain it.
I'm not sure that's the case here.
32-on-32 is already effectively unmaintained, so we're not suffering
in terms of keeping the 32-on-32 code reliable.
We're suffering from the complexity that 32-on-32 code places on the
rest of the XX-on-64 code that we do care about.
IOW if someone volunteered to maintain 32-on-32 that's not actually
solving the complexity problem, just perpetuating it.
The current maintainers only interested in XX-on-64 will still suffer
ongoing burden from the code complexity caused by 32-on-32 merely
existing.
So again lets be clear...
Either we...
* ...want to kill 32-on-32 code to reduce the complexity on the
main XX-on-64 codebase regardless of interest in 32-on-32
Or
* ...want to kill 32-on-32 code because it is buggy due to lack
of maintainers, but would welcome someone to step forward to
maintain it
It sounded like we were wanting the former, not the latter.
Yes, we want to former. But as Thomas pointed out, last time
someone showed up, and while the maintainers weren't willing to
keep 32-on-32 [*], they kept maintaining it at the price of restricting
XX-on-64.
[*] back then we proved system emulation XX-on-32 wasn't really useful
anymore, and user emulation 64-on-32 was partly broken, so only
32-on-32 user emulation was functional.