From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Hajnoczi, Stefan" <stefanha@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Liviu Ionescu" <ilg@livius.net>
Subject: Re: [PATCH 0/1] meson: Deprecate 32-bit host systems
Date: Fri, 31 Jan 2025 21:28:53 +0000 [thread overview]
Message-ID: <Z51AlWh80Pqou6h_@redhat.com> (raw)
In-Reply-To: <CABgObfYvYWxua7_TwYzWH99N5pR92Vsmv8Q=57FU_g5wSwmacw@mail.gmail.com>
On Fri, Jan 31, 2025 at 06:08:32PM +0100, Paolo Bonzini wrote:
> Il ven 31 gen 2025, 17:46 Richard Henderson <richard.henderson@linaro.org>
> ha scritto:
>
> > On 1/29/25 04:47, Paolo Bonzini wrote:
> > > The difference with TCG of course is that TCG is in active development,
> > and therefore its
> > > 32-bit host support is not surviving passively in the same way that a
> > random device is.
> > > Still, I think we can identify at least three different parts that
> > should be treated
> > > differently: 64-on-32, 32-on-32 system-mode emulation and 32-on-32
> > user-mode emulation.
> >
> > Why the user/system split for 32-on-32?
> >
>
> Various reasons which overall point at 32-on-32 system emulation being not
> used very much.
>
> 1) 32-bit has the address space size limitation, which makes it harder to
> test even moderately sized (2G) guests.
>
> 2) I might be wrong but user mode emulation has no equivalent of the
> forced-64bit hwaddr or ram_addr_t types; 32 bit is not very 32 bit anyway
> in the case of system emulation
>
> 3) 32-bit virtualization support only exists on x86 and possibly MIPS
>
> 4) system emulation is used mostly on development systems, whereas user
> mode emulation might be used on small systems to run short-lived
> proprietary programs
>
> 5) for those 32-bit hosts that have a completely separate TCG backend
> (well, that's Arm), getting rid TLB accesses does eliminate a bit of code.
These days perhaps one of the more (most?) common "linux-user" scenarios
I see is foreign arch containers. When telling docker/podman to run a
non- native container image, it relies on qemu-user to make it all work
transparently. Users probably don't even realize they're relying on
QEMU, things just look a little slower.
Given the prevalence of containers these days, if you have an OS install
whether 32-bit or 64-bit you're probably relying on podman/docker to some
extent. Those who need non-native containers is admittedly relatively
niche, but it wouldn't surprise me to hear of people doing it on 32-bit
machines.
In general I think the biggest problem we have is that users that are likely
to be impacted by our decisions won't pay any attention to QEMU upstream
at all. IOW they'll never see our deprecation announcement, and thus we
will never hear any feedback if they want it kept around
So perhaps we need to make a bit more effort to broadcast this particular
plan, given its more fundamental impact that most deprecations.
I'd suggest we should put out a qemu.org blog post post asking for feedback
on the proposal to drop 32-bit support. Then get people to publicise this
to their distro forums/mailing lists, and/or CC lwn.net to ask for it to be
featured it as a news item.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-01-31 21:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 0:42 [PATCH 0/1] meson: Deprecate 32-bit host systems Richard Henderson
2025-01-28 0:42 ` [PATCH 1/1] meson: Deprecate 32-bit host support Richard Henderson
2025-01-28 4:00 ` [PATCH 0/1] meson: Deprecate 32-bit host systems Thomas Huth
2025-01-28 9:02 ` Alex Bennée
2025-01-28 9:16 ` Daniel P. Berrangé
2025-01-28 9:17 ` Philippe Mathieu-Daudé
2025-01-28 9:27 ` Daniel P. Berrangé
2025-01-28 10:01 ` Philippe Mathieu-Daudé
2025-01-28 10:02 ` Philippe Mathieu-Daudé
2025-01-29 6:23 ` Thomas Huth
2025-01-29 12:23 ` Peter Maydell
2025-01-29 12:47 ` Paolo Bonzini
2025-01-31 16:46 ` Richard Henderson
2025-01-31 17:08 ` Paolo Bonzini
2025-01-31 21:28 ` Daniel P. Berrangé [this message]
2025-02-03 9:10 ` Alex Bennée
2025-02-03 16:06 ` Philippe Mathieu-Daudé
2025-01-28 20:39 ` Richard Henderson
2025-02-01 15:20 ` James Cloos
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=Z51AlWh80Pqou6h_@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=ilg@livius.net \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=stefanha@redhat.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).