чт, 16 мар. 2023 г., 11:31 Thomas Huth <th...@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é <phi...@linaro.org > >> <mailto:phi...@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 > >
