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

[Richard Henderson <richard.henderson@linaro.org>]

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~