From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
qemu-devel@nongnu.org,
"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
Date: Thu, 2 Apr 2026 17:37:30 +0100 [thread overview]
Message-ID: <ac6bSqRgUviOyXtF@redhat.com> (raw)
In-Reply-To: <988641b4-9e93-40eb-9742-63d8c1e17547@redhat.com>
On Thu, Apr 02, 2026 at 03:02:17PM +0200, Thomas Huth wrote:
> On 02/04/2026 13.20, Peter Maydell wrote:
> > On Thu, 2 Apr 2026 at 10:52, Thomas Huth <thuth@redhat.com> wrote:
> > >
> > > This is a follow-up to my 3-years old patch series here, now with the
> > > universal binary initiative in mind:
> > >
> > > https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg04541.html
> > >
> > > This patch series allows to run qemu-system-x86_64 in 32-bit-only mode
> > > (by renaming or symlinking the binary to "qemu-system-i386" or something
> > > similar with a "-i386" suffix). After doing this, qemu-system-x86_64
> > > should be a full superset of qemu-system-i386 (apart from 32-bit KVM
> > > support, which however is not required anymore now that we removed support
> > > for 32-bit hosts). It is now possible to migrate a guest that has been
> > > started with an old "qemu-system-i386" binary to a qemu-system-x86_64
> > > binary that has been renamed with a "-i386" suffix.
> >
> > I think my reaction here is similar to what it has been when
> > the similar idea has been raised for qemu-system-arm : we should
> > have a coordinated plan that is considering all architectures,
> > not just dropping a single binary for one architecture where
> > it happens to be more straightforward.
>
> Sure, I'm open for suggestions ... how should that coordinated plan look like?
> Maybe we could simply stop adding new versioned machine types to the 32-bit
> flavor binaries, and then let the old machine types expire? And when there
> is no versioned machine type left anymore, we could remove the 32-bit
> binaries?
On i686 the versioned machine types are shared with x86_64
and likewise arm7 'virt' machine is shared with aarch64.
So there's no concept of "stop adding machines" unless we
go out of our way to block what we're already doing for
64-bit from being used on 32-bit.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
next prev parent reply other threads:[~2026-04-02 16:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
2026-04-02 9:51 ` [PATCH 01/10] target/i386/tcg/sysemu: Move target specific SMM code to separate functions Thomas Huth
2026-04-02 9:51 ` [PATCH 02/10] target/i386/tcg/sysemu: Allow 32-bit SMM code to be used in the 64-bit binary Thomas Huth
2026-04-02 9:51 ` [PATCH 03/10] target-info: Add functions for querying whether the target is i386 or x86_64 Thomas Huth
2026-04-02 9:51 ` [PATCH 04/10] cpu: Add a way to detect 32-bit mode from argv0 Thomas Huth
2026-04-02 9:51 ` [PATCH 05/10] target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only Thomas Huth
2026-04-02 9:51 ` [PATCH 06/10] target/i386: Select a 32-bit/64-bit default CPU during runtime Thomas Huth
2026-04-02 9:51 ` [PATCH 07/10] target/i386: Adjust the suffix of the CPU devices to 32-bit/64-bit mode Thomas Huth
2026-04-02 9:51 ` [PATCH 08/10] hw/i386/isapc: Adjust the check for valid CPUs in the isapc machine Thomas Huth
2026-04-02 9:51 ` [PATCH 09/10] target/i386: Support migrating from i386 to x86_64 target Thomas Huth
2026-04-02 9:51 ` [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary Thomas Huth
2026-04-02 10:06 ` Daniel P. Berrangé
2026-04-02 10:11 ` Thomas Huth
2026-04-02 10:41 ` Daniel P. Berrangé
2026-04-02 10:44 ` Daniel P. Berrangé
2026-04-02 11:20 ` [PATCH for-11.1 00/10] " Peter Maydell
2026-04-02 13:02 ` Thomas Huth
2026-04-02 16:37 ` Daniel P. Berrangé [this message]
2026-04-02 16:44 ` Thomas Huth
2026-04-06 4:47 ` Pierrick Bouvier
2026-04-08 7:20 ` Thomas Huth
2026-04-08 15:42 ` Pierrick Bouvier
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=ac6bSqRgUviOyXtF@redhat.com \
--to=berrange@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=zhao1.liu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.