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.

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.


r~


Richard Henderson (1):
  meson: Deprecate 32-bit host support

 docs/about/deprecated.rst | 8 ++++++++
 meson.build               | 6 ++----
 2 files changed, 10 insertions(+), 4 deletions(-)

-- 
2.43.0

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?

> 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.

Sound like a good alternative to me!

  Thomas

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? 

>
> Sound like a good alternative to me!
>
>  Thomas

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

AB>   - even the Pi Zero 2W can work with a 64 bit OS.

not complaining about the idea, but the above is not entirely true.

i had to drop back to the 32 bit version to get the 802.11 to work.

they released a new version after i reported the bug, but that also
failed to work....

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

On Tue, Jan 28, 2025 at 09:02:48AM +0000, 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?

Last time we discussed this, we distinguished between system emulation
and linux-user. I believe Richard is proposing to deprecated *both*,
but lets call that out explicitly in any deprecation message to avoid
mis-understandings.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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.

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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 1/28/25 01:27, Daniel P. Berrangé wrote:
> 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.

Correct.

As evidence, on i686, the absolutely easiest available 32-bit host, we have the following 
failures with make check-functional:

>   2/185 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_rme_virt                  ERROR             1.50s   exit status 1
>   3/185 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_rme_sbsaref               ERROR             2.69s   exit status 1
>   4/185 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_virt                      ERROR           206.84s   exit status 1
>  12/185 qemu:func-thorough+func-ppc64-thorough+thorough / func-ppc64-ppc64_tuxrun                          ERROR             4.95s   exit status 1
>  17/185 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_aspeed                    TIMEOUT         600.01s   killed by signal 15 SIGTERM
>  24/185 qemu:func-thorough+func-ppc64-thorough+thorough / func-ppc64-ppc64_powernv                         TIMEOUT         480.01s   killed by signal 15 SIGTERM
> 115/185 qemu:func-quick+func-x86_64 / func-x86_64-mem_addr_space                                           ERROR             8.92s   exit status 1
> 132/185 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_xlnx_versal               ERROR             0.35s   exit status 1
> 147/185 qemu:func-thorough+func-m68k-thorough+thorough / func-m68k-m68k_q800                               ERROR             0.88s   exit status 1
> 156/185 qemu:func-thorough+func-riscv64-thorough+thorough / func-riscv64-riscv64_tuxrun                    TIMEOUT         120.01s   killed by signal 15 SIGTERM
> 163/185 qemu:func-thorough+func-x86_64-thorough+thorough / func-x86_64-x86_64_kvm_xen                      TIMEOUT         180.01s   killed by signal 15 SIGTERM
> 177/185 qemu:func-thorough+func-x86_64-thorough+thorough / func-x86_64-linux_initrd                        ERROR             0.35s   exit status 1
> 178/185 qemu:func-thorough+func-x86_64-thorough+thorough / func-x86_64-multiprocess                        ERROR             0.77s   exit status 1

8 of these are due to the test asking for more RAM than the host can provide to the guest.

   Output: qemu-system-aarch64: at most 2047 MB RAM can be simulated
   Output: qemu-system-ppc64: ram size 4294967296 exceeds permitted maximum 4294967295
   Output: qemu-system-x86_64: ram size 4294967296 exceeds permitted maximum 4294967295

Some are probably trivially fixable, simply by asking for less RAM.  But the point is that 
no one has reported the failures, and I can only conclude that no one cares about this 
host.  And if we can't keep i686 working, then other more obscure hosts have even less chance.

I'll also note that those error messages above are misleading -- in at least some of the 
x86_64 cases the command-line is "-m 512,slots=1,maxmem=59.6G".  So we're asking to 
reserve physical address space for almost 60G, which is not what the error message suggests.


> 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.

Correct.


> 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.
Correct.

Frankly, no one has stepped forward in the last 2 years, the last time we mooted 
deprecating all 32-bit hosts, but got talked out of it.  So I don't think option 2 is a 
real option.


r~

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.

On 28/1/25 11:01, Philippe Mathieu-Daudé wrote:
> 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.

So it seems reasonable to deprecate and ask interested 32-on-32 user
emulation users to use QEMU 10.1 release.

On 28/01/2025 11.02, Philippe Mathieu-Daudé wrote:
> On 28/1/25 11:01, Philippe Mathieu-Daudé wrote:
>> 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.
> 
> So it seems reasonable to deprecate and ask interested 32-on-32 user
> emulation users to use QEMU 10.1 release.

So unless someone complains immediately with a good reason, I'm also in 
favor of marking it as deprecated now. If then someone complains during the 
deprecation period, we still can reconsider and remove the deprecation note 
again.

Thus for this patch from my side:
Reviewed-by: Thomas Huth <thuth@redhat.com>

On Wed, 29 Jan 2025 at 06:23, Thomas Huth <thuth@redhat.com> wrote:
> So unless someone complains immediately with a good reason, I'm also in
> favor of marking it as deprecated now. If then someone complains during the
> deprecation period, we still can reconsider and remove the deprecation note
> again.

Well, I mean the reason would be that I suspect we do still have
users who are using QEMU for some purposes on 32-bit arm hosts.
That doesn't mean they're trying to run massively complex or
high memory guests or that they care that our whole test suite
doesn't run.

I'm not really strongly opposed to dropping 32-bit host support,
but I don't think a thread on qemu-devel is exactly likely to
get the attention of the people who might be using this
functionality. (You could argue that functionality without
representation among the developer community is fair game
for being dumped even if it has users, of course.)

-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 29 Jan 2025 at 06:23, Thomas Huth <thuth@redhat.com> wrote:
>> So unless someone complains immediately with a good reason, I'm also in
>> favor of marking it as deprecated now. If then someone complains during the
>> deprecation period, we still can reconsider and remove the deprecation note
>> again.
>
> Well, I mean the reason would be that I suspect we do still have
> users who are using QEMU for some purposes on 32-bit arm hosts.
> That doesn't mean they're trying to run massively complex or
> high memory guests or that they care that our whole test suite
> doesn't run.
>
> I'm not really strongly opposed to dropping 32-bit host support,
> but I don't think a thread on qemu-devel is exactly likely to
> get the attention of the people who might be using this
> functionality. (You could argue that functionality without
> representation among the developer community is fair game
> for being dumped even if it has users, of course.)

FWIW random internet poll:

  https://mastodon.org.uk/deck/@stsquad/113905257703721811

26% 32 bit
74% 64 bit

with 41 respondents.

>
> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On 3/2/25 10:10, Alex Bennée wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
>> On Wed, 29 Jan 2025 at 06:23, Thomas Huth <thuth@redhat.com> wrote:
>>> So unless someone complains immediately with a good reason, I'm also in
>>> favor of marking it as deprecated now. If then someone complains during the
>>> deprecation period, we still can reconsider and remove the deprecation note
>>> again.
>>
>> Well, I mean the reason would be that I suspect we do still have
>> users who are using QEMU for some purposes on 32-bit arm hosts.
>> That doesn't mean they're trying to run massively complex or
>> high memory guests or that they care that our whole test suite
>> doesn't run.
>>
>> I'm not really strongly opposed to dropping 32-bit host support,
>> but I don't think a thread on qemu-devel is exactly likely to
>> get the attention of the people who might be using this
>> functionality. (You could argue that functionality without
>> representation among the developer community is fair game
>> for being dumped even if it has users, of course.)
> 
> FWIW random internet poll:
> 
>    https://mastodon.org.uk/deck/@stsquad/113905257703721811
> 
> 26% 32 bit
> 74% 64 bit
> 
> with 41 respondents.

Note that some respondents who voted to maintain 32-bit support
mixed 32-bit host with 32-bit guests.

On 1/29/25 13:23, Peter Maydell wrote:
> I'm not really strongly opposed to dropping 32-bit host support,
> but I don't think a thread on qemu-devel is exactly likely to
> get the attention of the people who might be using this
> functionality. (You could argue that functionality without
> representation among the developer community is fair game
> for being dumped even if it has users, of course.)
On the other hand, broken tests that no one even runs among the 
developers are not particularly significant.  It's not surprising that 
tests do not pass the first time and need a little tweaking when trying 
them on a new platform.

There are many examples of parts of QEMU that stayed unmaintained for 
years, working relatively well for limited use cases, and were only 
later revamped.  Most of those that I can remember are guest side: the 
TCG frontend for x86, ESP emulation in hw/scsi, VGA.  In fact VGA still 
has a good number of emulation deficiencies and it's deprecated for 
virtualization use, but no one in their right mind would suggest slating 
it for removal.

The difference with TCG of course is that TCG is in active development, 
and therefore its 32-bit host support is not surviving passively in the 
same way that a random device is.  Still, I think we can identify at 
least three different parts that should be treated differently: 
64-on-32, 32-on-32 system-mode emulation and 32-on-32 user-mode emulation.

We could and should remove 64-on-32, maybe even without a deprecation 
period, but the rest I'm not so sure.  I don't know enough to understand 
their maintenance cost (other than the mere existence of the 32-bit TCG 
backends), but it's certainly not comparable to 64-on-32.

Paolo

On 1/29/25 04:47, Paolo Bonzini wrote:
> The difference with TCG of course is that TCG is in active development, and therefore its 
> 32-bit host support is not surviving passively in the same way that a random device is.  
> Still, I think we can identify at least three different parts that should be treated 
> differently: 64-on-32, 32-on-32 system-mode emulation and 32-on-32 user-mode emulation.

Why the user/system split for 32-on-32?

> We could and should remove 64-on-32, maybe even without a deprecation period, but the rest 
> I'm not so sure.  I don't know enough to understand their maintenance cost (other than the 
> mere existence of the 32-bit TCG backends), but it's certainly not comparable to 64-on-32.

Ok, lemme see how easy it is to prohibit configuring 64-on-32.

But I also think we should still deprecate 32-bit hosts, sooner rather than later.  Even 
if we have no immediate plans to remove them.  I think we want interested parties to speak 
up.  At some point this decade I want to be able to say: we've given you fair warning and 
time is up.


r~

Il ven 31 gen 2025, 17:46 Richard Henderson <richard.henderson@linaro.org>
ha scritto:

> On 1/29/25 04:47, Paolo Bonzini wrote:
> > The difference with TCG of course is that TCG is in active development,
> and therefore its
> > 32-bit host support is not surviving passively in the same way that a
> random device is.
> > Still, I think we can identify at least three different parts that
> should be treated
> > differently: 64-on-32, 32-on-32 system-mode emulation and 32-on-32
> user-mode emulation.
>
> Why the user/system split for 32-on-32?
>

Various reasons which overall point at 32-on-32 system emulation being not
used very much.

1) 32-bit has the address space size limitation, which makes it harder to
test even moderately sized (2G) guests.

2) I might be wrong but user mode emulation has no equivalent of the
forced-64bit hwaddr or ram_addr_t types; 32 bit is not very 32 bit anyway
in the case of system emulation

3) 32-bit virtualization support only exists on x86 and possibly MIPS

4) system emulation is used mostly on development systems, whereas user
mode emulation might be used on small systems to run short-lived
proprietary programs

5) for those 32-bit hosts that have a completely separate TCG backend
(well, that's Arm), getting rid TLB accesses does eliminate a bit of code.

None of them may be compelling, or maybe deprecating only one of the two
don't really make a difference in terms of maintainability, but this at
least makes the case for 32-on-32 system emulation a lot weaker.

More specifically, I don't believe anything other than 32-bit Arm hosts are
in user and for anything but user mode emulation, but those have a nonzero
chance of being in use.

> We could and should remove 64-on-32, maybe even without a deprecation
> period, but the rest
> > I'm not so sure.  I don't know enough to understand their maintenance
> cost (other than the
> > mere existence of the 32-bit TCG backends), but it's certainly not
> comparable to 64-on-32.
>
> Ok, lemme see how easy it is to prohibit configuring 64-on-32.
>

Probably very easy, and I would really want to do that without even a
deprecation period.

But I also think we should still deprecate 32-bit hosts, sooner rather than
> later.  Even
> if we have no immediate plans to remove them.  I think we want interested
> parties to speak
> up.  At some point this decade I want to be able to say: we've given you
> fair warning and
> time is up.
>

Fair enough. We have several deprecations that are in limbo and probably
won't go away soon, and it makes sense for 32-bit hosts to be another.

Also, I don't want this to look like stonewalling, so I will point out that
we can always decide to remove only *some* 32-bit hosts (or some 32-bit TCG
backends), once the deprecation countdown has ticked for some time.

Paolo

On Fri, Jan 31, 2025 at 06:08:32PM +0100, Paolo Bonzini wrote:
> Il ven 31 gen 2025, 17:46 Richard Henderson <richard.henderson@linaro.org>
> ha scritto:
> 
> > On 1/29/25 04:47, Paolo Bonzini wrote:
> > > The difference with TCG of course is that TCG is in active development,
> > and therefore its
> > > 32-bit host support is not surviving passively in the same way that a
> > random device is.
> > > Still, I think we can identify at least three different parts that
> > should be treated
> > > differently: 64-on-32, 32-on-32 system-mode emulation and 32-on-32
> > user-mode emulation.
> >
> > Why the user/system split for 32-on-32?
> >
> 
> Various reasons which overall point at 32-on-32 system emulation being not
> used very much.
> 
> 1) 32-bit has the address space size limitation, which makes it harder to
> test even moderately sized (2G) guests.
> 
> 2) I might be wrong but user mode emulation has no equivalent of the
> forced-64bit hwaddr or ram_addr_t types; 32 bit is not very 32 bit anyway
> in the case of system emulation
> 
> 3) 32-bit virtualization support only exists on x86 and possibly MIPS
> 
> 4) system emulation is used mostly on development systems, whereas user
> mode emulation might be used on small systems to run short-lived
> proprietary programs
> 
> 5) for those 32-bit hosts that have a completely separate TCG backend
> (well, that's Arm), getting rid TLB accesses does eliminate a bit of code.

These days perhaps one of the more (most?) common "linux-user" scenarios
I see is foreign arch containers. When telling docker/podman to run a
non- native container image, it relies on qemu-user to make it all work
transparently. Users probably don't even realize they're relying on
QEMU, things just look a little slower.

Given the prevalence of containers these days, if you have an OS install
whether 32-bit or 64-bit you're probably relying on podman/docker to some
extent. Those who need non-native containers is admittedly relatively
niche, but it wouldn't surprise me to hear of people doing it on 32-bit
machines.

In general I think the biggest problem we have is that users that are likely
to be impacted by our decisions won't pay any attention to QEMU upstream
at all. IOW they'll never see our deprecation announcement, and thus we
will never hear any feedback if they want it kept around

So perhaps we need to make a bit more effort to broadcast this particular
plan, given its more fundamental impact that most deprecations.

I'd suggest we should put out a qemu.org blog post post asking for feedback
on the proposal to drop 32-bit support. Then get people to publicise this
to their distro forums/mailing lists, and/or CC lwn.net to ask for it to be
featured it as a news item.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|