qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Andrew Randrianasulu <randrianasulu@gmail.com>
Cc: qemu-discuss@nongnu.org, QEMU Developers <qemu-devel@nongnu.org>,
	Thomas Huth <thuth@redhat.com>
Subject: Re: dropping 32-bit host support
Date: Thu, 16 Mar 2023 08:36:55 +0100	[thread overview]
Message-ID: <c33b0e07-5c46-6ebe-fe4c-5308ce508a70@linaro.org> (raw)
In-Reply-To: <CA+rFky5=kc0Pwf3RRhuKrBqtRVkmtm=NDKhrVgJV2_Ame2nUOQ@mail.gmail.com>

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)
>     is not
> 
>     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?

>     host: hardware where you run QEMU
>     guest: what is run within QEMU
> 
>     Running 32-bit *guest* on your 64-bit *host* is still supported.
> 
>     We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
>     Raspberry Pi 2 (host) for example.
> 
>      > going anywhere, but what about 32bit userspace on Android tablets,
>      > either via Limbo emulator or qemu itself in Termux?
> 
>     *System* emulation [on 32-bit hosts] is deprecated. User emulation
>     (such linux-user) is not. For example, you can still run 64-bit x86_64
>     Linux binaries on a 32-bit ARM Raspberry Pi.
> 
> 
> 
> Well, unrooted Android does not allow you to just load some perfectly 
> fine kernel module, so user-space emulation can't do all things 
> system-level one can. 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!

Huawei MatePad T8 is based on a MediaTek MT8768 CPU which contains
ARM Cortex-A53 cores. These cores implements the ARMv8-A 64-bit ISA,
so theoretically it is able to run a 64-bit Android.

>      > At least I hope it will be not *actively* (intentionally) broken,
>     just
>      > ...unsupported (so users who know how to run git revert still
>     will get
>      > their build for some more time).
> 
>     Unsupported code almost always unintentionally end bit-rotting...
> 
> 
> 
> 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.
> 
> 
> 
>     I hope this is clearer.
> 
>     Regards,
> 
>     Phil.
> 



  reply	other threads:[~2023-03-16  7:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+rFky6A9Q_5sJ4WDO-Z2HBT59qiNgr8A-xk+O7-gnAMZmHt2A@mail.gmail.com>
2023-03-16  7:05 ` dropping 32-bit host support Philippe Mathieu-Daudé
2023-03-16  7:17   ` Andrew Randrianasulu
2023-03-16  7:36     ` Philippe Mathieu-Daudé [this message]
2023-03-16  7:44       ` Andrew Randrianasulu
2023-03-16  8:31       ` Thomas Huth
2023-03-16  9:17         ` Andrew Randrianasulu
2023-03-16 10:22           ` Andrew Randrianasulu
2023-03-16 10:56             ` Philippe Mathieu-Daudé
2023-03-16 11:04               ` Andrew Randrianasulu
2023-03-16 11:15                 ` Thomas Huth
2023-03-16 11:02             ` Thomas Huth
2023-03-16 11:11               ` Andrew Randrianasulu
2023-03-16 12:35                 ` Daniel P. Berrangé
2023-03-16 13:01                   ` Andrew Randrianasulu
2023-03-16 13:32                     ` Thomas Huth
2023-03-16 15:21                       ` Warner Losh
2023-03-16 15:29                         ` Andrew Randrianasulu
2023-03-16 15:27                       ` Andrew Randrianasulu
2023-03-16 15:39                     ` Daniel P. Berrangé
2023-03-17  8:03                   ` Andrew Randrianasulu
2023-03-16 10:00         ` Markus Armbruster
2023-03-16 10:05           ` Andrew Randrianasulu
     [not found] ` <3DD8295F-4BE0-4262-8C68-4A85A56D63C7@livius.net>
2023-03-16  7:29   ` Philippe Mathieu-Daudé
2023-03-16  7:57     ` Liviu Ionescu
2023-03-16  8:07       ` Liviu Ionescu
2023-03-16  8:36         ` Thomas Huth
2023-03-16  8:42           ` Liviu Ionescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c33b0e07-5c46-6ebe-fe4c-5308ce508a70@linaro.org \
    --to=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@nongnu.org \
    --cc=randrianasulu@gmail.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).