From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 71AF9C6FD1F for ; Thu, 16 Mar 2023 10:23:58 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pckl8-0000zA-2D; Thu, 16 Mar 2023 06:22:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pckl6-0000yx-5b; Thu, 16 Mar 2023 06:22:56 -0400 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pckl3-00071P-Cx; Thu, 16 Mar 2023 06:22:55 -0400 Received: by mail-pj1-x1029.google.com with SMTP id rj10so1155627pjb.4; Thu, 16 Mar 2023 03:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678962171; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NDZeBiDBHSKDsckmtVcGzMMdhTYoLv3nsCkmh81whfs=; b=QOAc4iXLVbjARjO3sQkm3uQexERc4WDZmzB5J5GKNhPZjtPLuGWTRLndIAqlHjc8WL aYe553ewq4TMPldCAgwCI0rP3Ro64C5xy54CeN/THiDvfEDLhNDwUka9ihLtPyDTIxIJ hhZIYe9Im09Vun7Qy/pidG+/1FzHTJUl/Gv7U+Ba0f/LNP6g/F+reBAnk6pmXr12Wsfd 9HFDBxHSN2Gm8HY34df/BuaGjfKaBBQjxiRAhgWOjqkahv1E/M0GuyDyEKzpFJvkIowK QVY/ce3Jc8W5NwdGR1CrVT/hPPPS4KGFXkhdzq4CtxCWXgQJDBZkLmzg/k4aicjiEElT Ya0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678962171; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NDZeBiDBHSKDsckmtVcGzMMdhTYoLv3nsCkmh81whfs=; b=WCCm7qNC6Le7R0uTm07PPyo/VcvsiYBm0557YI16v8xxJ1VcypWbM+aL56nGBpbt5R jhCQfK1J0/hf7Zq1Ge0ktwrJNhAvrG5Ry1ikBIDsRTRlOpMS+bUIE2IKQUOLimDe4mIU ne3pc49ktqqSsBf4FcIHHvCcVIf3KoXgF5XWNPakrgHAS/l+ooFoBUQFVdXSF19YgKlm D/e4soVW5lqOZ4k80JJKgCrOH5qNXJIvDp2+TIpjXQyJG+eazEIG015F1mokTJDns/Y+ aMA8hqgAZRM9Wqy5uC4XUJPr/RDAgJuEEW/hhw8OuBCIHe6NMVR5/pxp11Wi/ocNOhMo cIvw== X-Gm-Message-State: AO0yUKXtnpz9mSPuoEtBPhM8G0x8gQFpNy3g2E/ohdz3WxKU76/V3TCj LFUgrnTT7n4wgmhElJk05M6v9uJbCaDFcYChhMY= X-Google-Smtp-Source: AK7set/NnIicHGptO/eo1qq/kcGaLbGzuoO4hjzwwjrjzjDraSwi/rBHP4nSFwjLvKF8a40/rvqT0SLYxys+KDtousA= X-Received: by 2002:a17:903:44d:b0:19f:35d3:ed0b with SMTP id iw13-20020a170903044d00b0019f35d3ed0bmr1184632plb.2.1678962171279; Thu, 16 Mar 2023 03:22:51 -0700 (PDT) MIME-Version: 1.0 References: <632e7256-34f5-ca87-ff60-a5c11aa1dd7f@redhat.com> In-Reply-To: From: Andrew Randrianasulu Date: Thu, 16 Mar 2023 13:22:38 +0300 Message-ID: Subject: Re: dropping 32-bit host support To: Thomas Huth Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , qemu-discuss@nongnu.org, QEMU Developers Content-Type: multipart/alternative; boundary="000000000000cf7d4805f701d74f" Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=randrianasulu@gmail.com; helo=mail-pj1-x1029.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --000000000000cf7d4805f701d74f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 12:17 Andrew Randrianasu= lu : > > > =D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 11:31 Thomas Huth : > >> On 16/03/2023 08.36, Philippe Mathieu-Daud=C3=A9 wrote: >> > On 16/3/23 08:17, Andrew Randrianasulu wrote: >> >> >> >> =D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 10:05 Philippe Mat= hieu-Daud=C3=A9 > >> >: >> >> >> >> Hi Andrew, >> >> >> >> On 16/3/23 01:57, Andrew Randrianasulu wrote: >> >> > Looking at https://wiki.qemu.org/ChangeLog/8.0 >> >> >> >> > > >> > >> >> > >> >> > =3D=3D=3D >> >> > System emulation on 32-bit x86 and ARM hosts has been >> deprecated. >> >> The >> >> > QEMU project no longer considers 32-bit x86 and ARM support fo= r >> >> system >> >> > emulation to be an effective use of its limited resources, and >> thus >> >> > intends to discontinue. >> >> > >> >> > =3D=3D >> >> > >> >> > well, I guess arguing from memory-consuption point on 32 bit x= 86 >> >> 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*. > I stand (self) corrected on *on disk* binary size, this parameter tend to be ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do not have full identical x64 Slackware setup for measuring memory impact. Still, pushing users into endless hw upgrade is no fun: https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-ma= kes-more-sense-than-recycling/ note e-waste and energy consumption This graph does not make me happy: https://ourworldindata.org/grapher/global-energy-substitution?time=3Dearlie= st..2021 Note this paradox too https://en.m.wikipedia.org/wiki/Jevons_paradox Yes, weirdly or not basically I talk about same thing as "we are running out of CI quota". But. With ~all developers following mindlessly into "upgrade now, think later if at all" whole dependency tree will be heavier and heavier. I guess whole move to gitlab also was not from overly good life .... I wonder of those c:\ paths I saw while looking into build status are real and mean CI running on Windows? Or it was just some strange fake thing ..... is Windows cheaper? Is it really better when it comes to containers? 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 o= f >> 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 make= s >> 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 hos= t. >> >> >> [...] 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, yo= u >> 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 ide= a. >> >> 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 leas= t >> 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 >> >> --000000000000cf7d4805f701d74f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 12:= 17 Andrew Randrianasulu <randrianasulu@gmail= .com>:


= =D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 11:31 Thomas Huth <thuth@redhat.com>:
On 16/03/2023 08.36, Philippe Mathieu-Daud=C3=A9 wrote:=
> On 16/3/23 08:17, Andrew Randrianasulu wrote:
>>
>> =D1=87=D1=82, 16 =D0=BC=D0=B0=D1=80. 2023 =D0=B3., 10:05 Philippe = Mathieu-Daud=C3=A9 <philmd@li= naro.org
>> <mailto:philmd@linar= o.org>>:
>>
>> =C2=A0=C2=A0=C2=A0 Hi Andrew,
>>
>> =C2=A0=C2=A0=C2=A0 On 16/3/23 01:57, Andrew Randrianasulu wrote: >> =C2=A0=C2=A0=C2=A0=C2=A0 > Looking at https://wiki.qemu.org/ChangeLog/8.0=
>> =C2=A0=C2=A0=C2=A0 <https://wiki.qemu.org/ChangeLog/8.0>
>> =C2=A0=C2=A0=C2=A0=C2=A0 > <https://wiki.qemu.org/ChangeLog/8.0 >> =C2=A0=C2=A0=C2=A0 <https://wiki.qemu.org/ChangeLog/8.0>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>> =C2=A0=C2=A0=C2=A0=C2=A0 > =3D=3D=3D
>> =C2=A0=C2=A0=C2=A0=C2=A0 > System emulation on 32-bit x86 and A= RM hosts has been deprecated.
>> =C2=A0=C2=A0=C2=A0 The
>> =C2=A0=C2=A0=C2=A0=C2=A0 > QEMU project no longer considers 32-= bit x86 and ARM support for
>> =C2=A0=C2=A0=C2=A0 system
>> =C2=A0=C2=A0=C2=A0=C2=A0 > emulation to be an effective use of = its limited resources, and thus
>> =C2=A0=C2=A0=C2=A0=C2=A0 > intends to discontinue.
>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>> =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0=3D=3D
>> =C2=A0=C2=A0=C2=A0=C2=A0 >
>> =C2=A0=C2=A0=C2=A0=C2=A0 > well, I guess arguing from memory-co= nsuption point on 32 bit x86
>> =C2=A0=C2=A0=C2=A0 hosts
>> =C2=A0=C2=A0=C2=A0=C2=A0 > (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*.

I stand (self) corrected o= n *on disk* binary size, this parameter tend to be ~same between bash / php= binaries from Slackware 15.0 i586/x86_64. I do not have full identical x64= Slackware setup for measuring memory impact.


Still, pushing users into= endless hw upgrade is no fun:


note e-waste and energy consumption

This graph does not make = me happy:


Note this paradox too


Yes, weirdly or not bas= ically I talk about same thing as "we are running out of CI=C2=A0 quot= a". But. With ~all developers following mindlessly into "upgrade = now, think later if at all" whole dependency tree will be heavier and = heavier.


I guess whole move to gitlab also was not from overly good lif= e .... I wonder of those c:\ paths I saw while looking into build status=C2= =A0 are real and mean CI running on Windows? Or it was just some strange fa= ke thing ..... is Windows cheaper? Is it really better when it comes to con= tainers?



Also, this whol= e "my program is only one running on user's machine"=C2=A0 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)=

>>
>> =C2=A0=C2=A0=C2=A0 If you use a 64-bit kernel, then your host is 6= 4-bit :)
>>
>>
>>
>> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 3= 2bit.
>> 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 an= d
fixing bugs.

Well, does this CI thing reuse build objects (even indirectly, vi= a ccache) currently?=C2=A0


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 <= br> 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 <= br> sure that the guest can only run in 32-bit mode.

>> =C2=A0=C2=A0=C2=A0 host: hardware where you run QEMU
>> =C2=A0=C2=A0=C2=A0 guest: what is run within QEMU
>>
>> =C2=A0=C2=A0=C2=A0 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 ho= st.

>> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Andr= oid,
>> 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 <= br> 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 (raytr= acing
>> kernels for Lux renderer). So, _sometimes_ it really not that cost= ly.
>> 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 m= achines
>> (and share patches, if they develop them, publicly) actually good = idea.

The problem is really that we don't have unlimited resources in the QEM= U
project. Currently we're heavily struggling with the load in the CI, bu= t
also pure man power is always very scarce. So at one point in time, you hav= e
to decide to say good bye to some old and hardly used features - at least t= o
stop testing and actively supporting it. If you want to continue testing an= d
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.

=C2=A0 Thomas

--000000000000cf7d4805f701d74f--