Re: [PATCH v2 00/14] meson: Deprecate 32-bit host support

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

Hi Jan,

On 4/2/25 10:11, Jan Beulich wrote:
> On 04.02.2025 09:19, Juergen Gross wrote:
>> On 03.02.25 23:43, Stefano Stabellini wrote:
>>> +Xen maintainers
>>>
>>>
>>> On Mon, 3 Feb 2025, Richard Henderson wrote:
>>>> On 2/3/25 04:54, Paolo Bonzini wrote:
>>>>> On 2/3/25 04:18, Richard Henderson wrote:
>>>>>> v1: 20250128004254.33442-1-richard.henderson@linaro.org
>>>>>>
>>>>>> For v2, immediately disable 64-on-32 TCG.
>>>>>>
>>>>>> I *suspect* that we should disable 64-on-32 for *all* accelerators.
>>>>>> The idea that an i686 binary on an x86_64 host may be used to spawn
>>>>>> an x86_64 guest via kvm is silly and a bit more than niche.
>>>>>
>>>>> At least Xen used to be commonly used with 32-bit dom0, because it saved
>>>>> memory and dom0 would map in guest buffers as needed.  I'm not sure how
>>>>> common that is these days, perhaps Stefano knows.
>>>>
>>>> As a data-point, debian does not ship libxen-dev for i686.
>>>> We cannot build-test this configuration at all.
>>>>
>>>> I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's
>>>> unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for
>>>> an armhf host, or as an armhf binary running on an aarch64 host.
>>>
>>>
>>> On the Xen side, there are two different use cases: x86 32-bit and ARM
>>> 32-bit.
>>>
>>> For x86 32-bit, while it was a very important use case in the past, I
>>> believe it is far less so now. I will let the x86 maintainers comment on
>>> how important it is today.
>>
>> As dom0 on x86 is a PV guest per default and Linux doesn't support running as a
>> 32-bit PV guest since a few years now, I guess there is no need to support qemu
>> as 32-bit on x86 for Xen.

This community disconnection between QEMU and Xen communities is a bit
unfortunate, as apparently we have been maintaining for some time
something that isn't used.

> Yet then, just to mention it, you can run a 64-bit PV Dom0 kernel underneath
> an otherwise 32-bit distro. I've been doing this successfully for very many
> years (with a very small kernel adjustment, just to work around an apparent
> shortcoming in system init scripts).

This discussion is about what is maintained by the mainstream projects.

We don't want to make fork's life harder. If you believe your use case
is worthwhile, please get it incorporated mainstream so we can test it.
Otherwise it is too much burden to maintain things we can not even test.

Regards,

Phil.