Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

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.