docs/about/deprecated.rst | 19 +++ include/qemu/target-info.h | 28 ++++ target/i386/cpu.h | 68 ++++++--- hw/i386/isapc.c | 18 ++- system/vl.c | 1 + target-info.c | 37 +++++ target/i386/cpu.c | 59 +++++--- target/i386/gdbstub.c | 2 +- target/i386/host-cpu.c | 6 +- target/i386/machine.c | 222 ++++++++++++++++++++++++++++ target/i386/tcg/system/smm_helper.c | 104 ++++++++----- 11 files changed, 483 insertions(+), 81 deletions(-)
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.
Thus we can finally deprecate the qemu-system-i386 binary. This will
help to avoid that we have to compile a lot of the x86 stuff twice
once we'll finally be able to drop qemu-system-i386 after the deprecation
period expired.
Thomas Huth (10):
target/i386/tcg/sysemu: Move target specific SMM code to separate
functions
target/i386/tcg/sysemu: Allow 32-bit SMM code to be used in the 64-bit
binary
target-info: Add functions for querying whether the target is i386 or
x86_64
cpu: Add a way to detect 32-bit mode from argv0
target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only
target/i386: Select a 32-bit/64-bit default CPU during runtime
target/i386: Adjust the suffix of the CPU devices to 32-bit/64-bit
mode
hw/i386/isapc: Adjust the check for valid CPUs in the isapc machine
target/i386: Support migrating from i386 to x86_64 target
docs/about/deprecated: Deprecate the qemu-system-i386 binary
docs/about/deprecated.rst | 19 +++
include/qemu/target-info.h | 28 ++++
target/i386/cpu.h | 68 ++++++---
hw/i386/isapc.c | 18 ++-
system/vl.c | 1 +
target-info.c | 37 +++++
target/i386/cpu.c | 59 +++++---
target/i386/gdbstub.c | 2 +-
target/i386/host-cpu.c | 6 +-
target/i386/machine.c | 222 ++++++++++++++++++++++++++++
target/i386/tcg/system/smm_helper.c | 104 ++++++++-----
11 files changed, 483 insertions(+), 81 deletions(-)
--
2.53.0
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. -- PMM
Hi everyone, On 4/2/26 4:20 AM, 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. > Thanks for posting this Thomas. > 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. > There are two things to consider for this series, and we should clarify what it is trying to do. The first one is the possibility to have a single-binary. The second one is to reduce the number of binaries qemu officially have. It does not impact the number of targets, since 32-bit ones will still be supported. We are currently working on Arm architecture with the first goal in mind. It does not bring anything useful in terms of feature, since qemu-system-aarch64 can already run anything that qemu-system-arm runs. However, it gives us a place to experiment and see how target code can efficiently and correctly modified to support the single-binary effort. We know it's not yet the final word on this, because other architecture makes more usage of target_ulong and TCGv, and we'll need another solution. Even if we create a plan to remove 32-bit targets when 64-bit ones support it, we will run into architectures that are an issue. Thus, I believe more strongly in refactoring the code, target after target. It will take time, but thanks to the single-binary approach, we can progress in iterations and in parallel, over years, and make sure there is no regression on files that have been ported. Let's fast forward 5 years in the future and imagine that all QEMU targets are integrated in the single-binary. Once it is done, we know that all files in target/X/* will be compiled only once, and integrated selectively for 32-bit or 64-bit targets. The key to understand is that in this setup, choosing to keep the 32-bit does not change anything. Technically, it will just be a simple target-info file, representing this 32-bit target, and a symlink for representing the target binary. All the rest will already be common with 64-bit. With this projection in mind, I wonder what is the concrete value to make any proper plan to deprecate 32-bit targets, since in the end, it won't matter if they are present or not. What are your thoughts? Which value would we get from deprecating 32-bit targets when possible? Regards, Pierrick
On 06/04/2026 06.47, Pierrick Bouvier wrote: > Hi everyone, > > On 4/2/26 4:20 AM, 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. >> > > Thanks for posting this Thomas. > >> 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. >> > > There are two things to consider for this series, and we should clarify what > it is trying to do. > > The first one is the possibility to have a single-binary. The second one is > to reduce the number of binaries qemu officially have. It does not impact > the number of targets, since 32-bit ones will still be supported. Agreed, thanks for pointing this out, Pierrick! Given the fact that the patch for declaring qemu-system-i386 as deprecated seems to have rather caused mixed feelings, I think we'd should rather postpone that discussion and focus on the patches that will be useful for the universal binary. ... > Let's fast forward 5 years in the future and imagine that all QEMU targets > are integrated in the single-binary. Once it is done, we know that all files > in target/X/* will be compiled only once, and integrated selectively for 32- > bit or 64-bit targets. The key to understand is that in this setup, choosing > to keep the 32-bit does not change anything. Technically, it will just be a > simple target-info file, representing this 32-bit target, and a symlink for > representing the target binary. All the rest will already be common with 64- > bit. > > With this projection in mind, I wonder what is the concrete value to make > any proper plan to deprecate 32-bit targets, since in the end, it won't > matter if they are present or not. > > What are your thoughts? > Which value would we get from deprecating 32-bit targets when possible? My concern with the i386 target is that you have to maintain the clunky additional vmstates for migration forever that way. It's just ugly, for very low benefit here (who is *really* still using the i386 32-bit target in 2026?). Also maintaining additional 32-bit targets increases our test matrix, i.e. we could shorten our CI times if we remove it one day. So let's keep this in mind. We don't have to deprecate the 32-bit targets right now, but if it's bothering us again in the future, we might want to reconsider to deprecate them. Thomas
On 4/8/26 12:20 AM, Thomas Huth wrote: > On 06/04/2026 06.47, Pierrick Bouvier wrote: >> Hi everyone, >> >> On 4/2/26 4:20 AM, 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. >>> >> >> Thanks for posting this Thomas. >> >>> 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. >>> >> >> There are two things to consider for this series, and we should clarify what >> it is trying to do. >> >> The first one is the possibility to have a single-binary. The second one is >> to reduce the number of binaries qemu officially have. It does not impact >> the number of targets, since 32-bit ones will still be supported. > > Agreed, thanks for pointing this out, Pierrick! > > Given the fact that the patch for declaring qemu-system-i386 as deprecated > seems to have rather caused mixed feelings, I think we'd should rather > postpone that discussion and focus on the patches that will be useful for > the universal binary. > > ... >> Let's fast forward 5 years in the future and imagine that all QEMU targets >> are integrated in the single-binary. Once it is done, we know that all files >> in target/X/* will be compiled only once, and integrated selectively for 32- >> bit or 64-bit targets. The key to understand is that in this setup, choosing >> to keep the 32-bit does not change anything. Technically, it will just be a >> simple target-info file, representing this 32-bit target, and a symlink for >> representing the target binary. All the rest will already be common with 64- >> bit. >> >> With this projection in mind, I wonder what is the concrete value to make >> any proper plan to deprecate 32-bit targets, since in the end, it won't >> matter if they are present or not. >> >> What are your thoughts? >> Which value would we get from deprecating 32-bit targets when possible? > > My concern with the i386 target is that you have to maintain the clunky > additional vmstates for migration forever that way. It's just ugly, for very > low benefit here (who is *really* still using the i386 32-bit target in 2026?). > I agree, it's probably not used nowadays. However, I suspect it's different for some other architectures when 32-bit are still active, and people are used to qemu 32-bit target binary. > Also maintaining additional 32-bit targets increases our test matrix, i.e. > we could shorten our CI times if we remove it one day. > > So let's keep this in mind. We don't have to deprecate the 32-bit targets > right now, but if it's bothering us again in the future, we might want to > reconsider to deprecate them. > From your feedback, it seems like this series is really focused on i386 architecture, and it does not seem like we should take further action to have a general policy of deprecation for other 32-bit targets. > Thomas > Regards, Pierrick
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? Thomas
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 :|
On 02/04/2026 18.37, Daniel P. Berrangé wrote:
> 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.
As an initial step, we could do something like this:
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -364,6 +364,8 @@ static void pc_q35_machine_options(MachineClass *m)
pc_q35_compat_defaults, pc_q35_compat_defaults_len);
}
+#ifdef TARGET_X86_64
+
static void pc_q35_machine_11_0_options(MachineClass *m)
{
pc_q35_machine_options(m);
@@ -371,6 +373,8 @@ static void pc_q35_machine_11_0_options(MachineClass *m)
DEFINE_Q35_MACHINE_AS_LATEST(11, 0);
+#endif
+
static void pc_q35_machine_10_2_options(MachineClass *m)
{
pc_q35_machine_11_0_options(m);
@@ -378,7 +382,11 @@ static void pc_q35_machine_10_2_options(MachineClass *m)
compat_props_add(m->compat_props, pc_compat_10_2, pc_compat_10_2_len);
}
+#ifdef TARGET_X86_64
DEFINE_Q35_MACHINE(10, 2);
+#else
+DEFINE_Q35_MACHINE_AS_LATEST(10, 2);
+#endif
static void pc_q35_machine_10_1_options(MachineClass *m)
{
... and similar patches for all other versioned machine types (i440fx and
arm virt).
Then wait for 6 years, and finally remove the 32 bit target binaries ;-)
Thomas
© 2016 - 2026 Red Hat, Inc.