Re: dropping 32-bit host support

[Andrew Randrianasulu <randrianasulu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4732 bytes --]

чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com>:

> On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >>
> >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org
> >> <mailto:philmd@linaro.org>>:
> >>
> >>     Hi Andrew,
> >>
> >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >>     <https://wiki.qemu.org/ChangeLog/8.0>
> >>      > <https://wiki.qemu.org/ChangeLog/8.0
> >>     <https://wiki.qemu.org/ChangeLog/8.0>>
> >>      >
> >>      > ===
> >>      > System emulation on 32-bit x86 and ARM hosts has been deprecated.
> >>     The
> >>      > QEMU project no longer considers 32-bit x86 and ARM support for
> >>     system
> >>      > emulation to be an effective use of its limited resources, and
> thus
> >>      > intends to discontinue.
> >>      >
> >>      >   ==
> >>      >
> >>      > well, I guess arguing from memory-consuption point on 32 bit x86
> >>     hosts
> >>      > (like my machine where I run 32 bit userspace on 64 bit kernel)
>
> All current PCs have multiple gigabytes of RAM, so using a 32-bit
> userspace
> to save some few bytes sounds weird.
>

I think difference more like in 20-30% (on disk and in ram), not *few
bytes*. Also, this whole "my program is only one running on user's
machine"  is flawed.



> (and in case you're talking about a very old PC that cannot be extened
> anymore, you're likely better off with an older version of QEMU anyway)
>
> >>
> >>     If you use a 64-bit kernel, then your host is 64-bit :)
> >>
> >>
> >>
> >> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit.
> >> So, qemu naturally will be 32-bit binary on my system.
> >
> > This configuration is still supported!
> >
> > Thomas, should we clarify yet again? Maybe adding examples?
>
> There are two aspects here:
>
> 1) 32-bit KVM support - this won't be supported in the future anymore.
> Since
> running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API,
> KVM
> also won't be possible anymore with a QEMU that has been compiled in
> 32-bit
> mode.
>
> 2) Compiling a 32-bit QEMU binary won't be officially supported anymore.
> We
> won't waste any more precious CI minutes on this (which is where we're
> struggling the most currently), and likely no active support for finding
> and
> fixing bugs.


Well, does this CI thing reuse build objects (even indirectly, via ccache)
currently?


But I guess we won't actively disable this possibility
> (especially since we did not deprecate the corresponding 32-bit linux-user
> emulation yet, so the emulation code will mostly still stay around).
>
> In the long run, we likely want to get rid of the separate compilation of
> the qemu-system-i386 binary, too, but that's still to be discussed. E.g.
> we
> could add a special run mode to the qemu-system-x86_64 instead that makes
> sure that the guest can only run in 32-bit mode.
>
> >>     host: hardware where you run QEMU
> >>     guest: what is run within QEMU
> >>
> >>     Running 32-bit *guest* on your 64-bit *host* is still supported.
>
> If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.
>
> >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android,
> >> too) for emulating old mac os 9. Yes, I can wait 10 min per guest boot.
> >> Fedora 36 armhf boots even slower on emulation!
>
> Yes, but for such scenarios, you can also use older versions of QEMU, you
> don't need the latest and greatest shiny QEMU version.
>
> >> Well, sometimes simple patch restores functionality. I patched for
> example
> >> olive-editor to run on 32 bit, and before this intel embree (raytracing
> >> kernels for Lux renderer). So, _sometimes_ it really not that costly.
> >> While if this CI thing really runs per-commit and thrown away each
> result
> >> ... may be letting interested users to build things on their own
> machines
> >> (and share patches, if they develop them, publicly) actually good idea.
>
> The problem is really that we don't have unlimited resources in the QEMU
> project. Currently we're heavily struggling with the load in the CI, but
> also pure man power is always very scarce. So at one point in time, you
> have
> to decide to say good bye to some old and hardly used features - at least
> to
> stop testing and actively supporting it. If you want to continue testing
> and
> fixing bugs for such host systems, that's fine, of course, but don't
> expect
> the QEMU developers to do that job in the future.
>
>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 6746 bytes --]