* [PATCH 01/10] target/i386/tcg/sysemu: Move target specific SMM code to separate functions
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
@ 2026-04-02 9:51 ` 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
` (9 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
This code movement will make the next patch easier to read.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/tcg/system/smm_helper.c | 47 ++++++++++++++++++-----------
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/target/i386/tcg/system/smm_helper.c b/target/i386/tcg/system/smm_helper.c
index fb028a8272f..3be78cd53d3 100644
--- a/target/i386/tcg/system/smm_helper.c
+++ b/target/i386/tcg/system/smm_helper.c
@@ -32,26 +32,13 @@
#define SMM_REVISION_ID 0x00020000
#endif
-void do_smm_enter(X86CPU *cpu)
+static void sm_state_init(X86CPU *cpu)
{
CPUX86State *env = &cpu->env;
CPUState *cs = CPU(cpu);
- target_ulong sm_state;
SegmentCache *dt;
int i, offset;
-
- qemu_log_mask(CPU_LOG_INT, "SMM: enter\n");
- log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), CPU_DUMP_CCOP);
-
- env->msr_smi_count++;
- env->hflags |= HF_SMM_MASK;
- if (env->hflags2 & HF2_NMI_MASK) {
- env->hflags2 |= HF2_SMM_INSIDE_NMI_MASK;
- } else {
- env->hflags2 |= HF2_NMI_MASK;
- }
-
- sm_state = env->smbase + 0x8000;
+ target_ulong sm_state = env->smbase + 0x8000;
#ifdef TARGET_X86_64
for (i = 0; i < 6; i++) {
@@ -156,6 +143,25 @@ void do_smm_enter(X86CPU *cpu)
x86_stl_phys(cs, sm_state + 0x7efc, SMM_REVISION_ID);
x86_stl_phys(cs, sm_state + 0x7ef8, env->smbase);
#endif
+}
+
+void do_smm_enter(X86CPU *cpu)
+{
+ CPUX86State *env = &cpu->env;
+
+ qemu_log_mask(CPU_LOG_INT, "SMM: enter\n");
+ log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), CPU_DUMP_CCOP);
+
+ env->msr_smi_count++;
+ env->hflags |= HF_SMM_MASK;
+ if (env->hflags2 & HF2_NMI_MASK) {
+ env->hflags2 |= HF2_SMM_INSIDE_NMI_MASK;
+ } else {
+ env->hflags2 |= HF2_NMI_MASK;
+ }
+
+ sm_state_init(cpu);
+
/* init SMM cpu state */
#ifdef TARGET_X86_64
@@ -191,9 +197,8 @@ void do_smm_enter(X86CPU *cpu)
DESC_G_MASK | DESC_A_MASK);
}
-void helper_rsm(CPUX86State *env)
+static void rsm_load_regs(CPUX86State *env)
{
- X86CPU *cpu = env_archcpu(env);
CPUState *cs = env_cpu(env);
target_ulong sm_state;
int i, offset;
@@ -308,6 +313,14 @@ void helper_rsm(CPUX86State *env)
env->smbase = x86_ldl_phys(cs, sm_state + 0x7ef8);
}
#endif
+}
+
+void helper_rsm(CPUX86State *env)
+{
+ X86CPU *cpu = env_archcpu(env);
+
+ rsm_load_regs(env);
+
if ((env->hflags2 & HF2_SMM_INSIDE_NMI_MASK) == 0) {
env->hflags2 &= ~HF2_NMI_MASK;
}
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 02/10] target/i386/tcg/sysemu: Allow 32-bit SMM code to be used in the 64-bit binary
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 ` 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
` (8 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
This is a preparation for the QEMU universal binary where we might want
to support both, the x86_64 and the i386 target, in one binary. Instead
of using #ifdef TARGET_X86_64 here, check the LM bit to select the 32-bit
or 64-bit code during runtime.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/tcg/system/smm_helper.c | 65 +++++++++++++++++++----------
1 file changed, 43 insertions(+), 22 deletions(-)
diff --git a/target/i386/tcg/system/smm_helper.c b/target/i386/tcg/system/smm_helper.c
index 3be78cd53d3..4bbe18a86fb 100644
--- a/target/i386/tcg/system/smm_helper.c
+++ b/target/i386/tcg/system/smm_helper.c
@@ -23,24 +23,15 @@
#include "exec/log.h"
#include "tcg/helper-tcg.h"
-
-/* SMM support */
-
-#ifdef TARGET_X86_64
-#define SMM_REVISION_ID 0x00020064
-#else
-#define SMM_REVISION_ID 0x00020000
-#endif
-
-static void sm_state_init(X86CPU *cpu)
+static void sm_state_init_64(X86CPU *cpu)
{
+#ifdef TARGET_X86_64
CPUX86State *env = &cpu->env;
CPUState *cs = CPU(cpu);
SegmentCache *dt;
int i, offset;
target_ulong sm_state = env->smbase + 0x8000;
-#ifdef TARGET_X86_64
for (i = 0; i < 6; i++) {
dt = &env->segs[i];
offset = 0x7e00 + i * 16;
@@ -92,9 +83,21 @@ static void sm_state_init(X86CPU *cpu)
x86_stq_phys(cs, sm_state + 0x7f50, env->cr[3]);
x86_stl_phys(cs, sm_state + 0x7f58, env->cr[0]);
- x86_stl_phys(cs, sm_state + 0x7efc, SMM_REVISION_ID);
+ x86_stl_phys(cs, sm_state + 0x7efc, 0x00020064); /* SMM revision ID */
x86_stl_phys(cs, sm_state + 0x7f00, env->smbase);
#else
+ g_assert_not_reached();
+#endif
+}
+
+static void sm_state_init_32(X86CPU *cpu)
+{
+ CPUX86State *env = &cpu->env;
+ CPUState *cs = CPU(cpu);
+ SegmentCache *dt;
+ int i, offset;
+ target_ulong sm_state = env->smbase + 0x8000;
+
x86_stl_phys(cs, sm_state + 0x7ffc, env->cr[0]);
x86_stl_phys(cs, sm_state + 0x7ff8, env->cr[3]);
x86_stl_phys(cs, sm_state + 0x7ff4, cpu_compute_eflags(env));
@@ -140,9 +143,8 @@ static void sm_state_init(X86CPU *cpu)
}
x86_stl_phys(cs, sm_state + 0x7f14, env->cr[4]);
- x86_stl_phys(cs, sm_state + 0x7efc, SMM_REVISION_ID);
+ x86_stl_phys(cs, sm_state + 0x7efc, 0x00020000); /* SMM revision ID */
x86_stl_phys(cs, sm_state + 0x7ef8, env->smbase);
-#endif
}
void do_smm_enter(X86CPU *cpu)
@@ -160,13 +162,15 @@ void do_smm_enter(X86CPU *cpu)
env->hflags2 |= HF2_NMI_MASK;
}
- sm_state_init(cpu);
+ if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
+ sm_state_init_64(cpu);
+ cpu_load_efer(env, 0);
+ } else {
+ sm_state_init_32(cpu);
+ }
/* init SMM cpu state */
-#ifdef TARGET_X86_64
- cpu_load_efer(env, 0);
-#endif
cpu_load_eflags(env, 0, ~(CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C |
DF_MASK));
env->eip = 0x00008000;
@@ -197,15 +201,16 @@ void do_smm_enter(X86CPU *cpu)
DESC_G_MASK | DESC_A_MASK);
}
-static void rsm_load_regs(CPUX86State *env)
+static void rsm_load_regs_64(CPUX86State *env)
{
+#ifdef TARGET_X86_64
CPUState *cs = env_cpu(env);
target_ulong sm_state;
int i, offset;
uint32_t val;
sm_state = env->smbase + 0x8000;
-#ifdef TARGET_X86_64
+
cpu_load_efer(env, x86_ldq_phys(cs, sm_state + 0x7ed0));
env->gdt.base = x86_ldq_phys(cs, sm_state + 0x7e68);
@@ -260,6 +265,19 @@ static void rsm_load_regs(CPUX86State *env)
env->smbase = x86_ldl_phys(cs, sm_state + 0x7f00);
}
#else
+ g_assert_not_reached();
+#endif
+}
+
+static void rsm_load_regs_32(CPUX86State *env)
+{
+ CPUState *cs = env_cpu(env);
+ target_ulong sm_state;
+ int i, offset;
+ uint32_t val;
+
+ sm_state = env->smbase + 0x8000;
+
cpu_x86_update_cr0(env, x86_ldl_phys(cs, sm_state + 0x7ffc));
cpu_x86_update_cr3(env, x86_ldl_phys(cs, sm_state + 0x7ff8));
cpu_load_eflags(env, x86_ldl_phys(cs, sm_state + 0x7ff4),
@@ -312,14 +330,17 @@ static void rsm_load_regs(CPUX86State *env)
if (val & 0x20000) {
env->smbase = x86_ldl_phys(cs, sm_state + 0x7ef8);
}
-#endif
}
void helper_rsm(CPUX86State *env)
{
X86CPU *cpu = env_archcpu(env);
- rsm_load_regs(env);
+ if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
+ rsm_load_regs_64(env);
+ } else {
+ rsm_load_regs_32(env);
+ }
if ((env->hflags2 & HF2_SMM_INSIDE_NMI_MASK) == 0) {
env->hflags2 &= ~HF2_NMI_MASK;
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 03/10] target-info: Add functions for querying whether the target is i386 or x86_64
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 ` Thomas Huth
2026-04-02 9:51 ` [PATCH 04/10] cpu: Add a way to detect 32-bit mode from argv0 Thomas Huth
` (7 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
As we already have functions for querying whether the target architecture
is one of the various ppc, arm or s390x flavours, add now some functions
for x86, too, which will come in handy to decide during runtime whether
we are running in 32 or 64-bit mode in the x86 targets.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
include/qemu/target-info.h | 21 +++++++++++++++++++++
target-info.c | 21 +++++++++++++++++++++
2 files changed, 42 insertions(+)
diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 23c997de541..0713ab4bb16 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -99,4 +99,25 @@ bool target_ppc64(void);
*/
bool target_s390x(void);
+/**
+ * target_base_x86:
+ *
+ * Returns whether the target architecture is x86 (32-bit or 64-bit).
+ */
+bool target_base_x86(void);
+
+/**
+ * target_i386:
+ *
+ * Returns whether the target architecture is x86 32-bit.
+ */
+bool target_i386(void);
+
+/**
+ * target_x86_64:
+ *
+ * Returns whether the target architecture is x86 64-bit.
+ */
+bool target_x86_64(void);
+
#endif
diff --git a/target-info.c b/target-info.c
index 28c458fc7a7..dea73b5fbca 100644
--- a/target-info.c
+++ b/target-info.c
@@ -93,3 +93,24 @@ bool target_s390x(void)
{
return target_arch() == SYS_EMU_TARGET_S390X;
}
+
+bool target_base_x86(void)
+{
+ switch (target_arch()) {
+ case SYS_EMU_TARGET_I386:
+ case SYS_EMU_TARGET_X86_64:
+ return true;
+ default:
+ return false;
+ }
+}
+
+bool target_i386(void)
+{
+ return target_arch() == SYS_EMU_TARGET_I386;
+}
+
+bool target_x86_64(void)
+{
+ return target_arch() == SYS_EMU_TARGET_X86_64;
+}
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 04/10] cpu: Add a way to detect 32-bit mode from argv0
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (2 preceding siblings ...)
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 ` 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
` (6 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
In the future, we might want to avoid compiling certain targets separately
for 32-bit mode (i.e. -i386, -arm and -ppc) where the 64-bit variant is a
superset of the 32-bit variant. But it would be good to provide a way to
mimic the 32-bit behavior via the program name in case the users need this
compatibility for some scenarios. Thus add a function that checks
for the old 32-bit program names and sets a flag accordingly.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
include/qemu/target-info.h | 7 +++++++
system/vl.c | 1 +
target-info.c | 20 ++++++++++++++++++--
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 0713ab4bb16..aa9b2e9b0cf 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -9,6 +9,13 @@
#ifndef QEMU_TARGET_INFO_H
#define QEMU_TARGET_INFO_H
+/**
+ * target_info_adjust:
+ *
+ * Returns: Adjust the target according to the binary name of the executable.
+ */
+void target_info_adjust(const char *argv0);
+
/**
* target_name:
*
diff --git a/system/vl.c b/system/vl.c
index 246623b3196..45c9f5d5c7a 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -2884,6 +2884,7 @@ void qemu_init(int argc, char **argv)
error_init(argv[0]);
qemu_init_exec_dir(argv[0]);
+ target_info_adjust(argv[0]);
os_setup_limits();
diff --git a/target-info.c b/target-info.c
index dea73b5fbca..b18fd4e0060 100644
--- a/target-info.c
+++ b/target-info.c
@@ -12,6 +12,21 @@
#include "qemu/target-info-impl.h"
#include "qapi/error.h"
+static bool force_32bit;
+
+void target_info_adjust(const char *argv0)
+{
+ switch (target_arch()) {
+ case SYS_EMU_TARGET_X86_64:
+ if (g_str_has_suffix(argv0, "-i386")) {
+ force_32bit = true;
+ }
+ break;
+ default:
+ break;
+ }
+}
+
const char *target_name(void)
{
return target_info()->target_name;
@@ -107,10 +122,11 @@ bool target_base_x86(void)
bool target_i386(void)
{
- return target_arch() == SYS_EMU_TARGET_I386;
+ return target_arch() == SYS_EMU_TARGET_I386 ||
+ (target_arch() == SYS_EMU_TARGET_X86_64 && force_32bit);
}
bool target_x86_64(void)
{
- return target_arch() == SYS_EMU_TARGET_X86_64;
+ return target_arch() == SYS_EMU_TARGET_X86_64 && !force_32bit;
}
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 05/10] target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (3 preceding siblings ...)
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 ` Thomas Huth
2026-04-02 9:51 ` [PATCH 06/10] target/i386: Select a 32-bit/64-bit default CPU during runtime Thomas Huth
` (5 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
qemu-system-x86_64 is pretty much a proper superset of qemu-system-i386,
so in the long run, it does not make too much sense that we continuously
build two binaries here, we should deprecate the latter rather sooner
than later.
However, some people still might want to start QEMU in a mode that limits
the environment to 32-bit. Thus allow qemu-system-x86_64 to run in 32-bit
mode if the binary name ends in "-i386".
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/cpu.h | 15 +++------------
target/i386/cpu.c | 20 ++++++++++----------
target/i386/gdbstub.c | 2 +-
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 0b539155c40..9cb357aa797 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -36,13 +36,8 @@
#define XEN_NR_VIRQS 24
-#ifdef TARGET_X86_64
-#define I386_ELF_MACHINE EM_X86_64
-#define ELF_MACHINE_UNAME "x86_64"
-#else
-#define I386_ELF_MACHINE EM_386
-#define ELF_MACHINE_UNAME "i686"
-#endif
+#define I386_ELF_MACHINE (target_x86_64() ? EM_X86_64 : EM_386)
+#define ELF_MACHINE_UNAME (target_x86_64() ? "x86_64" : "i686")
enum {
R_EAX = 0,
@@ -277,11 +272,7 @@ typedef enum X86Seg {
#define CR4_PKS_MASK (1U << 24)
#define CR4_LAM_SUP_MASK (1U << 28)
-#ifdef TARGET_X86_64
-#define CR4_FRED_MASK (1ULL << 32)
-#else
-#define CR4_FRED_MASK 0
-#endif
+#define CR4_FRED_MASK (target_x86_64() ? (1ULL << 32) : 0)
#define CR4_RESERVED_MASK \
(~(target_ulong)(CR4_VME_MASK | CR4_PVI_MASK | CR4_TSD_MASK \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c6fd1dc00eb..e30d47831d6 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -8094,18 +8094,18 @@ uint64_t x86_cpu_get_supported_feature_word(X86CPU *cpu, FeatureWord w)
}
switch (w) {
-#ifndef TARGET_X86_64
case FEAT_8000_0001_EDX:
/*
* 32-bit TCG can emulate 64-bit compatibility mode. If there is no
* way for userspace to get out of its 32-bit jail, we can leave
* the LM bit set.
*/
- unavail = tcg_enabled()
- ? CPUID_EXT2_LM & ~CPUID_EXT2_KERNEL_FEATURES
- : CPUID_EXT2_LM;
+ if (target_i386()) {
+ unavail = tcg_enabled()
+ ? CPUID_EXT2_LM & ~CPUID_EXT2_KERNEL_FEATURES
+ : CPUID_EXT2_LM;
+ }
break;
-#endif
case FEAT_8000_0007_EBX:
if (cpu && !IS_AMD_CPU(&cpu->env)) {
@@ -8351,11 +8351,11 @@ static void x86_cpu_load_model(X86CPU *cpu, const X86CPUModel *model)
static const gchar *x86_gdb_arch_name(CPUState *cs)
{
-#ifdef TARGET_X86_64
- return "i386:x86-64";
-#else
- return "i386";
-#endif
+ if (target_x86_64()) {
+ return "i386:x86-64";
+ } else {
+ return "i386";
+ }
}
static void x86_cpu_cpudef_class_init(ObjectClass *oc, const void *data)
diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
index 5c5fa727216..951c443e6d2 100644
--- a/target/i386/gdbstub.c
+++ b/target/i386/gdbstub.c
@@ -498,7 +498,7 @@ void x86_cpu_gdb_init(CPUState *cs)
#ifdef TARGET_X86_64
CPUX86State *env = &X86_CPU(cs)->env;
- if (env->features[FEAT_7_1_EDX] & CPUID_7_1_EDX_APXF) {
+ if (target_x86_64() && (env->features[FEAT_7_1_EDX] & CPUID_7_1_EDX_APXF)) {
gdb_register_coprocessor(cs, i386_cpu_gdb_get_egprs,
i386_cpu_gdb_set_egprs,
gdb_find_static_feature("i386-64bit-apx.xml"));
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 06/10] target/i386: Select a 32-bit/64-bit default CPU during runtime
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (4 preceding siblings ...)
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 ` 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
` (4 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
For supporting both, the i386 and the x86_64 target in one binary,
TARGET_DEFAULT_CPU_TYPE needs to be adjusted during runtime.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/cpu.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 9cb357aa797..9d71d1dcca7 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2777,7 +2777,9 @@ uint64_t cpu_get_tsc(CPUX86State *env);
#define CPU_RESOLVING_TYPE TYPE_X86_CPU
#ifdef TARGET_X86_64
-#define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu64")
+#define TARGET_DEFAULT_CPU_TYPE \
+ (target_i386() ? X86_CPU_TYPE_NAME("qemu32") \
+ : X86_CPU_TYPE_NAME("qemu64"))
#else
#define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu32")
#endif
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 07/10] target/i386: Adjust the suffix of the CPU devices to 32-bit/64-bit mode
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (5 preceding siblings ...)
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 ` 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
` (3 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
qemu-system-i386 uses the suffix "-i386-cpu" for the CPU devices, while
qemu-system-x86_64 uses the suffix "-x86_64-cpu" instead. For supporting
both targets in one binary, we have to adjust the suffix during runtime.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/cpu.h | 3 ++-
target/i386/cpu.c | 29 ++++++++++++++++++++++++-----
target/i386/host-cpu.c | 6 +++++-
3 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 9d71d1dcca7..38309773ea8 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2775,10 +2775,11 @@ void cpu_x86_update_dr7(CPUX86State *env, uint32_t new_dr7);
uint64_t cpu_get_tsc(CPUX86State *env);
#define CPU_RESOLVING_TYPE TYPE_X86_CPU
+#define I386_CPU_TYPE_SUFFIX "-i386-cpu"
#ifdef TARGET_X86_64
#define TARGET_DEFAULT_CPU_TYPE \
- (target_i386() ? X86_CPU_TYPE_NAME("qemu32") \
+ (target_i386() ? "qemu32" I386_CPU_TYPE_SUFFIX \
: X86_CPU_TYPE_NAME("qemu64"))
#else
#define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu32")
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e30d47831d6..98e03cb9a88 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2276,7 +2276,11 @@ void host_cpuid(uint32_t function, uint32_t count,
*/
static char *x86_cpu_type_name(const char *model_name)
{
- return g_strdup_printf(X86_CPU_TYPE_NAME("%s"), model_name);
+ if (target_i386()) {
+ return g_strdup_printf("%s" I386_CPU_TYPE_SUFFIX, model_name);
+ } else {
+ return g_strdup_printf(X86_CPU_TYPE_NAME("%s"), model_name);
+ }
}
static ObjectClass *x86_cpu_class_by_name(const char *cpu_model)
@@ -2288,7 +2292,16 @@ static ObjectClass *x86_cpu_class_by_name(const char *cpu_model)
static char *x86_cpu_class_get_model_name(X86CPUClass *cc)
{
const char *class_name = object_class_get_name(OBJECT_CLASS(cc));
- assert(g_str_has_suffix(class_name, X86_CPU_TYPE_SUFFIX));
+ const char *type_suffix;
+
+ if (target_i386()) {
+ type_suffix = I386_CPU_TYPE_SUFFIX;
+ } else {
+ type_suffix = X86_CPU_TYPE_SUFFIX;
+ }
+
+ assert(g_str_has_suffix(class_name, type_suffix));
+
return cpu_model_from_type(class_name);
}
@@ -7266,7 +7279,7 @@ static void max_x86_cpu_initfn(Object *obj)
}
}
-static const TypeInfo max_x86_cpu_type_info = {
+static TypeInfo max_x86_cpu_type_info = {
.name = X86_CPU_TYPE_NAME("max"),
.parent = TYPE_X86_CPU,
.instance_init = max_x86_cpu_initfn,
@@ -7884,7 +7897,8 @@ static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b, gpointer d)
static GSList *get_sorted_cpu_model_list(void)
{
- GSList *list = object_class_get_list(TYPE_X86_CPU, false);
+ GSList *list = object_class_get_list(target_i386() ?
+ "i386-cpu" : TYPE_X86_CPU, false);
list = g_slist_sort_with_data(list, x86_cpu_list_compare, NULL);
return list;
}
@@ -10818,7 +10832,7 @@ static void x86_cpu_base_class_init(ObjectClass *oc, const void *data)
xcc->ordering = 8;
}
-static const TypeInfo x86_base_cpu_type_info = {
+static TypeInfo x86_base_cpu_type_info = {
.name = X86_CPU_TYPE_NAME("base"),
.parent = TYPE_X86_CPU,
.class_init = x86_cpu_base_class_init,
@@ -10832,6 +10846,11 @@ static void x86_cpu_register_types(void)
for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
x86_register_cpudef_types(&builtin_x86_defs[i]);
}
+
+ if (target_i386()) {
+ x86_base_cpu_type_info.name = "base" I386_CPU_TYPE_SUFFIX;
+ max_x86_cpu_type_info.name = "max" I386_CPU_TYPE_SUFFIX;
+ }
type_register_static(&max_x86_cpu_type_info);
type_register_static(&x86_base_cpu_type_info);
}
diff --git a/target/i386/host-cpu.c b/target/i386/host-cpu.c
index d5e2bb5e187..a6b8bb484b3 100644
--- a/target/i386/host-cpu.c
+++ b/target/i386/host-cpu.c
@@ -179,7 +179,7 @@ static void host_cpu_class_init(ObjectClass *oc, const void *data)
g_strdup_printf("processor with all supported host features ");
}
-static const TypeInfo host_cpu_type_info = {
+static TypeInfo host_cpu_type_info = {
.name = X86_CPU_TYPE_NAME("host"),
.parent = X86_CPU_TYPE_NAME("max"),
.class_init = host_cpu_class_init,
@@ -187,6 +187,10 @@ static const TypeInfo host_cpu_type_info = {
static void host_cpu_type_init(void)
{
+ if (target_i386()) {
+ host_cpu_type_info.name = "host" I386_CPU_TYPE_SUFFIX;
+ host_cpu_type_info.parent = "max" I386_CPU_TYPE_SUFFIX;
+ }
type_register_static(&host_cpu_type_info);
}
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 08/10] hw/i386/isapc: Adjust the check for valid CPUs in the isapc machine
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (6 preceding siblings ...)
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 ` Thomas Huth
2026-04-02 9:51 ` [PATCH 09/10] target/i386: Support migrating from i386 to x86_64 target Thomas Huth
` (2 subsequent siblings)
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
Now that we can run in both, x86_64 and i386 mode with one binary,
we must not hard-code the suffix of the CPU names here anymore.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/cpu.h | 1 +
hw/i386/isapc.c | 18 ++++++++++--------
target/i386/cpu.c | 2 +-
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 38309773ea8..78f2dadc2e3 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2722,6 +2722,7 @@ void mark_unavailable_features(X86CPU *cpu, FeatureWord w, uint64_t mask,
const char *verbose_prefix);
void mark_forced_on_features(X86CPU *cpu, FeatureWord w, uint64_t mask,
const char *verbose_prefix);
+char *x86_cpu_type_name(const char *model_name);
static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
{
diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
index 1ba9ae22cc3..c772b7f533a 100644
--- a/hw/i386/isapc.c
+++ b/hw/i386/isapc.c
@@ -43,13 +43,13 @@ static void pc_init_isa(MachineState *machine)
bool valid_cpu_type = false;
static const char * const valid_cpu_types[] = {
- X86_CPU_TYPE_NAME("486"),
- X86_CPU_TYPE_NAME("athlon"),
- X86_CPU_TYPE_NAME("kvm32"),
- X86_CPU_TYPE_NAME("pentium"),
- X86_CPU_TYPE_NAME("pentium2"),
- X86_CPU_TYPE_NAME("pentium3"),
- X86_CPU_TYPE_NAME("qemu32"),
+ "486",
+ "athlon",
+ "kvm32",
+ "pentium",
+ "pentium2",
+ "pentium3",
+ "qemu32",
};
/*
@@ -59,8 +59,10 @@ static void pc_init_isa(MachineState *machine)
* a warning if anyone tries to use a deprecated CPU.
*/
for (i = 0; i < ARRAY_SIZE(valid_cpu_types); i++) {
- if (!strcmp(machine->cpu_type, valid_cpu_types[i])) {
+ g_autofree char *valid_cpu = x86_cpu_type_name(valid_cpu_types[i]);
+ if (!strcmp(machine->cpu_type, valid_cpu)) {
valid_cpu_type = true;
+ break;
}
}
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 98e03cb9a88..a8ff1b29f33 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2274,7 +2274,7 @@ void host_cpuid(uint32_t function, uint32_t count,
/* Return type name for a given CPU model name
* Caller is responsible for freeing the returned string.
*/
-static char *x86_cpu_type_name(const char *model_name)
+char *x86_cpu_type_name(const char *model_name)
{
if (target_i386()) {
return g_strdup_printf("%s" I386_CPU_TYPE_SUFFIX, model_name);
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 09/10] target/i386: Support migrating from i386 to x86_64 target
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (7 preceding siblings ...)
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 ` Thomas Huth
2026-04-02 9:51 ` [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary Thomas Huth
2026-04-02 11:20 ` [PATCH for-11.1 00/10] " Peter Maydell
10 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
For migrating from qemu-system-i386 to qemu-system-x86_64, we have
to support the CPU vmstate of the 32-bit target.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/i386/cpu.h | 47 +++++++--
target/i386/cpu.c | 8 +-
target/i386/machine.c | 222 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 270 insertions(+), 7 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 78f2dadc2e3..88fcf44fdc0 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1632,6 +1632,13 @@ typedef struct SegmentCache {
uint32_t flags;
} SegmentCache;
+typedef struct SegmentCache32 {
+ uint32_t selector;
+ uint32_t base;
+ uint32_t limit;
+ uint32_t flags;
+} SegmentCache32;
+
typedef union MMXReg {
uint8_t _b_MMXReg[64 / 8];
uint16_t _w_MMXReg[64 / 16];
@@ -1974,10 +1981,16 @@ typedef struct CPUCaches {
typedef struct CPUArchState {
/* standard registers */
target_ulong regs[CPU_NB_EREGS];
- target_ulong eip;
- target_ulong eflags; /* eflags register. During CPU emulation, CC
- flags and DF are set to zero because they are
- stored elsewhere */
+ union {
+ target_ulong eip;
+ uint32_t eip32;
+ };
+ union {
+ target_ulong eflags; /* eflags register. During CPU emulation, CC
+ flags and DF are set to zero because they are
+ stored elsewhere */
+ uint32_t eflags32;
+ };
/* emulator internal eflags handling */
target_ulong cc_dst;
@@ -2042,8 +2055,14 @@ typedef struct CPUArchState {
/* sysenter registers */
uint32_t sysenter_cs;
- target_ulong sysenter_esp;
- target_ulong sysenter_eip;
+ union {
+ target_ulong sysenter_esp;
+ uint32_t sysenter_esp32;
+ };
+ union {
+ target_ulong sysenter_eip;
+ uint32_t sysenter_eip32;
+ };
uint64_t star;
uint64_t vm_hsave;
@@ -2294,6 +2313,21 @@ typedef struct CPUArchState {
uint16_t fptag_vmstate;
uint16_t fpregs_format_vmstate;
+#ifdef TARGET_X86_64
+ /*
+ * These fields are only used for migrating from qemu-system-i386
+ * to qemu-system-x86_64
+ */
+ uint32_t regs32[CPU_NB_REGS32];
+ SegmentCache32 segs32[6]; /* selector values */
+ SegmentCache32 ldt32;
+ SegmentCache32 tr32;
+ SegmentCache32 gdt32; /* only base and limit are used */
+ SegmentCache32 idt32; /* only base and limit are used */
+ uint32_t cr32[5];
+ uint32_t dr32[8];
+#endif
+
uint64_t xss;
uint32_t umwait;
@@ -2546,6 +2580,7 @@ struct X86CPUClass {
#ifndef CONFIG_USER_ONLY
extern const VMStateDescription vmstate_x86_cpu;
+extern const VMStateDescription vmstate_i386_cpu;
#endif
int x86_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cpu,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a8ff1b29f33..a087a45dbfe 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -10701,7 +10701,7 @@ static const Property x86_cpu_properties[] = {
#ifndef CONFIG_USER_ONLY
#include "hw/core/sysemu-cpu-ops.h"
-static const struct SysemuCPUOps i386_sysemu_ops = {
+static struct SysemuCPUOps i386_sysemu_ops = {
.has_work = x86_cpu_has_work,
.get_memory_mapping = x86_cpu_get_memory_mapping,
.get_paging_enabled = x86_cpu_get_paging_enabled,
@@ -10746,8 +10746,14 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data)
#ifndef CONFIG_USER_ONLY
cc->max_as = X86ASIdx_MAX;
+#ifdef TARGET_X86_64
+ if (target_i386()) {
+ i386_sysemu_ops.legacy_vmsd = &vmstate_i386_cpu;
+ }
+#endif
cc->sysemu_ops = &i386_sysemu_ops;
#endif /* !CONFIG_USER_ONLY */
+
#ifdef CONFIG_TCG
cc->tcg_ops = &x86_tcg_ops;
#endif /* CONFIG_TCG */
diff --git a/target/i386/machine.c b/target/i386/machine.c
index 48a2a4b3190..bb6019d3419 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -310,6 +310,44 @@ static int cpu_pre_save(void *opaque)
return 0;
}
+
+#ifdef TARGET_X86_64
+static void copy_segcache(SegmentCache32 *sc32, SegmentCache *sc64)
+{
+ sc64->selector = sc32->selector;
+ sc64->base = sc32->base;
+ sc64->limit = sc32->limit;
+ sc64->flags = sc32->flags;
+}
+#endif
+
+static void cpu_post_load_fixup32(CPUX86State *env)
+{
+#ifdef TARGET_X86_64
+ int i;
+
+ for (i = 0; i < CPU_NB_REGS32; i++) {
+ env->regs[i] = env->regs32[i];
+ }
+
+ for (i = 0; i < ARRAY_SIZE(env->segs); i++) {
+ copy_segcache(&env->segs32[i], &env->segs[i]);
+ }
+
+ copy_segcache(&env->ldt32, &env->ldt);
+ copy_segcache(&env->tr32, &env->tr);
+ copy_segcache(&env->gdt32, &env->gdt);
+ copy_segcache(&env->idt32, &env->idt);
+
+ for (i = 0; i < ARRAY_SIZE(env->cr); i++) {
+ env->cr[i] = env->cr32[i];
+ }
+ for (i = 0; i < ARRAY_SIZE(env->dr); i++) {
+ env->dr[i] = env->dr32[i];
+ }
+#endif
+}
+
static int cpu_post_load(void *opaque, int version_id)
{
X86CPU *cpu = opaque;
@@ -317,6 +355,10 @@ static int cpu_post_load(void *opaque, int version_id)
CPUX86State *env = &cpu->env;
int i;
+ if (target_i386()) {
+ cpu_post_load_fixup32(env);
+ }
+
if (env->tsc_khz && env->user_tsc_khz &&
env->tsc_khz != env->user_tsc_khz) {
error_report("Mismatch between user-specified TSC frequency and "
@@ -1920,3 +1962,183 @@ const VMStateDescription vmstate_x86_cpu = {
NULL
}
};
+
+/* ***************** 32-bit target hacks below **************** */
+
+#ifdef TARGET_X86_64
+
+static const VMStateDescription vmstate_segment32 = {
+ .name = "segment",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (const VMStateField[]) {
+ VMSTATE_UINT32(selector, SegmentCache32),
+ VMSTATE_UINT32(base, SegmentCache32),
+ VMSTATE_UINT32(limit, SegmentCache32),
+ VMSTATE_UINT32(flags, SegmentCache32),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+#define VMSTATE_SEGMENT32(_field, _state) { \
+ .name = (stringify(_field)), \
+ .size = sizeof(SegmentCache32), \
+ .vmsd = &vmstate_segment32, \
+ .flags = VMS_STRUCT, \
+ .offset = offsetof(_state, _field) \
+ + type_check(SegmentCache32, typeof_field(_state, _field)) \
+}
+
+#define VMSTATE_SEGMENT32_ARRAY(_field, _state, _n) \
+ VMSTATE_STRUCT_ARRAY(_field, _state, _n, 0, vmstate_segment32, SegmentCache32)
+
+#define VMSTATE_XMM32_REGS(_field, _state, _start) \
+ VMSTATE_STRUCT_SUB_ARRAY(_field, _state, _start, CPU_NB_REGS32, 0, \
+ vmstate_xmm_reg, ZMMReg)
+
+#define VMSTATE_YMMH32_REGS_VARS(_field, _state, _start, _v) \
+ VMSTATE_STRUCT_SUB_ARRAY(_field, _state, _start, CPU_NB_REGS32, _v, \
+ vmstate_ymmh_reg, ZMMReg)
+
+const VMStateDescription vmstate_i386_cpu = {
+ .name = "cpu",
+ .version_id = 12,
+ .minimum_version_id = 11,
+ .pre_save = cpu_pre_save,
+ .post_load = cpu_post_load,
+ .fields = (const VMStateField[]) {
+ VMSTATE_UINT32_SUB_ARRAY(env.regs32, X86CPU, 0, CPU_NB_REGS32),
+ VMSTATE_UINT32(env.eip32, X86CPU),
+ VMSTATE_UINT32(env.eflags32, X86CPU),
+ VMSTATE_UINT32(env.hflags, X86CPU),
+ /* FPU */
+ VMSTATE_UINT16(env.fpuc, X86CPU),
+ VMSTATE_UINT16(env.fpus_vmstate, X86CPU),
+ VMSTATE_UINT16(env.fptag_vmstate, X86CPU),
+ VMSTATE_UINT16(env.fpregs_format_vmstate, X86CPU),
+
+ VMSTATE_STRUCT_ARRAY(env.fpregs, X86CPU, 8, 0, vmstate_fpreg, FPReg),
+
+ VMSTATE_SEGMENT32_ARRAY(env.segs32, X86CPU, 6),
+ VMSTATE_SEGMENT32(env.ldt32, X86CPU),
+ VMSTATE_SEGMENT32(env.tr32, X86CPU),
+ VMSTATE_SEGMENT32(env.gdt32, X86CPU),
+ VMSTATE_SEGMENT32(env.idt32, X86CPU),
+
+ VMSTATE_UINT32(env.sysenter_cs, X86CPU),
+ VMSTATE_UINT32(env.sysenter_esp32, X86CPU),
+ VMSTATE_UINT32(env.sysenter_eip32, X86CPU),
+
+ VMSTATE_UINT32(env.cr32[0], X86CPU),
+ VMSTATE_UINT32(env.cr32[2], X86CPU),
+ VMSTATE_UINT32(env.cr32[3], X86CPU),
+ VMSTATE_UINT32(env.cr32[4], X86CPU),
+ VMSTATE_UINT32_ARRAY(env.dr32, X86CPU, 8),
+ /* MMU */
+ VMSTATE_INT32(env.a20_mask, X86CPU),
+ /* XMM */
+ VMSTATE_UINT32(env.mxcsr, X86CPU),
+ VMSTATE_XMM32_REGS(env.xmm_regs, X86CPU, 0),
+
+ VMSTATE_UINT32(env.smbase, X86CPU),
+
+ VMSTATE_UINT64(env.pat, X86CPU),
+ VMSTATE_UINT32(env.hflags2, X86CPU),
+
+ VMSTATE_UINT64(env.vm_hsave, X86CPU),
+ VMSTATE_UINT64(env.vm_vmcb, X86CPU),
+ VMSTATE_UINT64(env.tsc_offset, X86CPU),
+ VMSTATE_UINT64(env.intercept, X86CPU),
+ VMSTATE_UINT16(env.intercept_cr_read, X86CPU),
+ VMSTATE_UINT16(env.intercept_cr_write, X86CPU),
+ VMSTATE_UINT16(env.intercept_dr_read, X86CPU),
+ VMSTATE_UINT16(env.intercept_dr_write, X86CPU),
+ VMSTATE_UINT32(env.intercept_exceptions, X86CPU),
+ VMSTATE_UINT8(env.v_tpr, X86CPU),
+ /* MTRRs */
+ VMSTATE_UINT64_ARRAY(env.mtrr_fixed, X86CPU, 11),
+ VMSTATE_UINT64(env.mtrr_deftype, X86CPU),
+ VMSTATE_MTRR_VARS(env.mtrr_var, X86CPU, MSR_MTRRcap_VCNT, 8),
+ /* KVM-related states */
+ VMSTATE_INT32(env.interrupt_injected, X86CPU),
+ VMSTATE_UINT32(env.mp_state, X86CPU),
+ VMSTATE_UINT64(env.tsc, X86CPU),
+ VMSTATE_INT32(env.exception_nr, X86CPU),
+ VMSTATE_UINT8(env.soft_interrupt, X86CPU),
+ VMSTATE_UINT8(env.nmi_injected, X86CPU),
+ VMSTATE_UINT8(env.nmi_pending, X86CPU),
+ VMSTATE_UINT8(env.has_error_code, X86CPU),
+ VMSTATE_UINT32(env.sipi_vector, X86CPU),
+ /* MCE */
+ VMSTATE_UINT64(env.mcg_cap, X86CPU),
+ VMSTATE_UINT64(env.mcg_status, X86CPU),
+ VMSTATE_UINT64(env.mcg_ctl, X86CPU),
+ VMSTATE_UINT64_ARRAY(env.mce_banks, X86CPU, MCE_BANKS_DEF * 4),
+ /* rdtscp */
+ VMSTATE_UINT64(env.tsc_aux, X86CPU),
+ /* KVM pvclock msr */
+ VMSTATE_UINT64(env.system_time_msr, X86CPU),
+ VMSTATE_UINT64(env.wall_clock_msr, X86CPU),
+ /* XSAVE related fields */
+ VMSTATE_UINT64_V(env.xcr0, X86CPU, 12),
+ VMSTATE_UINT64_V(env.xstate_bv, X86CPU, 12),
+ VMSTATE_YMMH32_REGS_VARS(env.xmm_regs, X86CPU, 0, 12),
+ VMSTATE_END_OF_LIST()
+ /* The above list is not sorted /wrt version numbers, watch out! */
+ },
+ .subsections = (const VMStateDescription * const []) {
+ &vmstate_exception_info,
+ &vmstate_error_code,
+ &vmstate_async_pf_msr,
+ &vmstate_async_pf_int_msr,
+ &vmstate_pv_eoi_msr,
+ &vmstate_steal_time_msr,
+ &vmstate_poll_control_msr,
+ &vmstate_fpop_ip_dp,
+ &vmstate_msr_tsc_adjust,
+ &vmstate_msr_tscdeadline,
+ &vmstate_msr_ia32_misc_enable,
+ &vmstate_msr_ia32_feature_control,
+ &vmstate_msr_architectural_pmu,
+ &vmstate_mpx,
+ &vmstate_msr_hyperv_hypercall,
+ &vmstate_msr_hyperv_vapic,
+ &vmstate_msr_hyperv_time,
+ &vmstate_msr_hyperv_crash,
+ &vmstate_msr_hyperv_runtime,
+ &vmstate_msr_hyperv_synic,
+ &vmstate_msr_hyperv_stimer,
+ &vmstate_msr_hyperv_reenlightenment,
+ &vmstate_avx512,
+ &vmstate_xss,
+ &vmstate_umwait,
+ &vmstate_tsc_khz,
+ &vmstate_msr_smi_count,
+ &vmstate_pkru,
+ &vmstate_pkrs,
+ &vmstate_spec_ctrl,
+ &amd_tsc_scale_msr_ctrl,
+ &vmstate_mcg_ext_ctl,
+ &vmstate_msr_intel_pt,
+ &vmstate_msr_virt_ssbd,
+ &vmstate_svm_npt,
+ &vmstate_svm_guest,
+#ifdef CONFIG_KVM
+ &vmstate_nested_state,
+ &vmstate_xen_vcpu,
+#endif
+ &vmstate_msr_tsx_ctrl,
+ &vmstate_msr_intel_sgx,
+ &vmstate_pdptrs,
+ &vmstate_msr_xfd,
+ &vmstate_msr_hwcr,
+ &vmstate_arch_lbr,
+ &vmstate_triple_fault,
+ &vmstate_pl0_ssp,
+ &vmstate_cet,
+
+ NULL
+ }
+};
+
+#endif /* TARGET_X86_64 */
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (8 preceding siblings ...)
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 ` Thomas Huth
2026-04-02 10:06 ` Daniel P. Berrangé
2026-04-02 11:20 ` [PATCH for-11.1 00/10] " Peter Maydell
10 siblings, 1 reply; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 9:51 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Pierrick Bouvier, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu, Thomas Huth
From: Thomas Huth <thuth@redhat.com>
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. And with
the 32-bit x86 host support being removed now, it is possible to
deprecate the qemu-system-i386 binary now, too.
With regards to 32-bit KVM support in the x86 Linux kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
docs/about/deprecated.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a6d6a713265..2de51337d75 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
command line (``-M spike``).
+System emulator binaries
+------------------------
+
+``qemu-system-i386`` binary (since 11.1)
+''''''''''''''''''''''''''''''''''''''''
+
+The ``qemu-system-i386`` binary was mainly useful for running with KVM
+on 32-bit x86 hosts, but most Linux distributions already removed their
+support for 32-bit x86 kernels, so hardly anybody still needs this. The
+``qemu-system-x86_64`` binary is a proper superset and can be used to
+run 32-bit guests by selecting a 32-bit CPU model, including KVM support
+on x86_64 hosts. Thus users are recommended to reconfigure their systems
+to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
+environment should be enforced, you can switch off the "long mode" CPU
+flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
+to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
+disabled.
+
+
Backend options
---------------
--
2.53.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary
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
0 siblings, 1 reply; 22+ messages in thread
From: Daniel P. Berrangé @ 2026-04-02 10:06 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, qemu-devel, Pierrick Bouvier, Michael S. Tsirkin,
Richard Henderson, Philippe Mathieu-Daudé, Zhao Liu
On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> From: Thomas Huth <thuth@redhat.com>
>
> Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> binary is a proper superset of the qemu-system-i386 binary. And with
> the 32-bit x86 host support being removed now, it is possible to
> deprecate the qemu-system-i386 binary now, too.
>
> With regards to 32-bit KVM support in the x86 Linux kernel,
> the developers confirmed that they do not need a recent
> qemu-system-i386 binary here:
>
> https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> docs/about/deprecated.rst | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index a6d6a713265..2de51337d75 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
> command line (``-M spike``).
>
>
> +System emulator binaries
> +------------------------
> +
> +``qemu-system-i386`` binary (since 11.1)
> +''''''''''''''''''''''''''''''''''''''''
> +
> +The ``qemu-system-i386`` binary was mainly useful for running with KVM
> +on 32-bit x86 hosts, but most Linux distributions already removed their
> +support for 32-bit x86 kernels, so hardly anybody still needs this. The
> +``qemu-system-x86_64`` binary is a proper superset and can be used to
> +run 32-bit guests by selecting a 32-bit CPU model, including KVM support
> +on x86_64 hosts. Thus users are recommended to reconfigure their systems
> +to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
> +environment should be enforced, you can switch off the "long mode" CPU
> +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> +disabled.
Why don't we just have our install rules create the symlink from
qemu-system-x86_64 to qemu-system-i386. That gives us near zero
ongoing maint cost, without need to deprecate stuff / impact users
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 :|
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary
2026-04-02 10:06 ` Daniel P. Berrangé
@ 2026-04-02 10:11 ` Thomas Huth
2026-04-02 10:41 ` Daniel P. Berrangé
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 10:11 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Paolo Bonzini, qemu-devel, Pierrick Bouvier, Michael S. Tsirkin,
Richard Henderson, Philippe Mathieu-Daudé, Zhao Liu
On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
>> binary is a proper superset of the qemu-system-i386 binary. And with
>> the 32-bit x86 host support being removed now, it is possible to
>> deprecate the qemu-system-i386 binary now, too.
>>
>> With regards to 32-bit KVM support in the x86 Linux kernel,
>> the developers confirmed that they do not need a recent
>> qemu-system-i386 binary here:
>>
>> https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
>>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>> docs/about/deprecated.rst | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index a6d6a713265..2de51337d75 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
>> command line (``-M spike``).
>>
>>
>> +System emulator binaries
>> +------------------------
>> +
>> +``qemu-system-i386`` binary (since 11.1)
>> +''''''''''''''''''''''''''''''''''''''''
>> +
>> +The ``qemu-system-i386`` binary was mainly useful for running with KVM
>> +on 32-bit x86 hosts, but most Linux distributions already removed their
>> +support for 32-bit x86 kernels, so hardly anybody still needs this. The
>> +``qemu-system-x86_64`` binary is a proper superset and can be used to
>> +run 32-bit guests by selecting a 32-bit CPU model, including KVM support
>> +on x86_64 hosts. Thus users are recommended to reconfigure their systems
>> +to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
>> +environment should be enforced, you can switch off the "long mode" CPU
>> +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
>> +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
>> +disabled.
>
> Why don't we just have our install rules create the symlink from
> qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> ongoing maint cost, without need to deprecate stuff / impact users
I think we should do that once the deprecation period is over and we don't
allow to build QEMU in this mode anymore. I would rather not jump directly
to that state to provide people some time for experimenting whether this new
approach works as expected in all scenarios that are in use.
Thomas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary
2026-04-02 10:11 ` Thomas Huth
@ 2026-04-02 10:41 ` Daniel P. Berrangé
2026-04-02 10:44 ` Daniel P. Berrangé
0 siblings, 1 reply; 22+ messages in thread
From: Daniel P. Berrangé @ 2026-04-02 10:41 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, qemu-devel, Pierrick Bouvier, Michael S. Tsirkin,
Richard Henderson, Philippe Mathieu-Daudé, Zhao Liu
On Thu, Apr 02, 2026 at 12:11:37PM +0200, Thomas Huth wrote:
> On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> > On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> > > From: Thomas Huth <thuth@redhat.com>
> > >
> > > Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> > > binary is a proper superset of the qemu-system-i386 binary. And with
> > > the 32-bit x86 host support being removed now, it is possible to
> > > deprecate the qemu-system-i386 binary now, too.
> > >
> > > With regards to 32-bit KVM support in the x86 Linux kernel,
> > > the developers confirmed that they do not need a recent
> > > qemu-system-i386 binary here:
> > >
> > > https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
> > >
> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > ---
> > > docs/about/deprecated.rst | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > > index a6d6a713265..2de51337d75 100644
> > > --- a/docs/about/deprecated.rst
> > > +++ b/docs/about/deprecated.rst
> > > @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
> > > command line (``-M spike``).
> > > +System emulator binaries
> > > +------------------------
> > > +
> > > +``qemu-system-i386`` binary (since 11.1)
> > > +''''''''''''''''''''''''''''''''''''''''
> > > +
> > > +The ``qemu-system-i386`` binary was mainly useful for running with KVM
> > > +on 32-bit x86 hosts, but most Linux distributions already removed their
> > > +support for 32-bit x86 kernels, so hardly anybody still needs this. The
> > > +``qemu-system-x86_64`` binary is a proper superset and can be used to
> > > +run 32-bit guests by selecting a 32-bit CPU model, including KVM support
> > > +on x86_64 hosts. Thus users are recommended to reconfigure their systems
> > > +to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
> > > +environment should be enforced, you can switch off the "long mode" CPU
> > > +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> > > +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> > > +disabled.
> >
> > Why don't we just have our install rules create the symlink from
> > qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> > ongoing maint cost, without need to deprecate stuff / impact users
>
> I think we should do that once the deprecation period is over and we don't
> allow to build QEMU in this mode anymore. I would rather not jump directly
> to that state to provide people some time for experimenting whether this new
> approach works as expected in all scenarios that are in use.
This feels a bit wierd as a deprecation though. We're telling people
not to use qemu-system-i386 and yet we intend to continue providing
it via a symlink and expect full back compatibility and people can
carry on with it forever.
I think this is probably something better handled via a build time
option & messages from
* Step 1: full i686 binary by default but have --enable-i686-compat
to switch to symlink. Issue hint message that symlink will
become the default in future & asking for feedback if
--enable-i686-compat is not given
* Step 2: symlink i686 binary by default but have --disable-i686-compat
to switch to full binary. Issue *WARNING* that full binary
will be soon removed if --disable-i686-compat is given
* Step 3: remove full binary
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 :|
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary
2026-04-02 10:41 ` Daniel P. Berrangé
@ 2026-04-02 10:44 ` Daniel P. Berrangé
0 siblings, 0 replies; 22+ messages in thread
From: Daniel P. Berrangé @ 2026-04-02 10:44 UTC (permalink / raw)
To: Thomas Huth, Paolo Bonzini, qemu-devel, Pierrick Bouvier,
Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
On Thu, Apr 02, 2026 at 11:41:02AM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 02, 2026 at 12:11:37PM +0200, Thomas Huth wrote:
> > On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> > > On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> > > > From: Thomas Huth <thuth@redhat.com>
> > > >
> > > > Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> > > > binary is a proper superset of the qemu-system-i386 binary. And with
> > > > the 32-bit x86 host support being removed now, it is possible to
> > > > deprecate the qemu-system-i386 binary now, too.
> > > >
> > > > With regards to 32-bit KVM support in the x86 Linux kernel,
> > > > the developers confirmed that they do not need a recent
> > > > qemu-system-i386 binary here:
> > > >
> > > > https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
> > > >
> > > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > ---
> > > > docs/about/deprecated.rst | 19 +++++++++++++++++++
> > > > 1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > > > index a6d6a713265..2de51337d75 100644
> > > > --- a/docs/about/deprecated.rst
> > > > +++ b/docs/about/deprecated.rst
> > > > @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
> > > > command line (``-M spike``).
> > > > +System emulator binaries
> > > > +------------------------
> > > > +
> > > > +``qemu-system-i386`` binary (since 11.1)
> > > > +''''''''''''''''''''''''''''''''''''''''
> > > > +
> > > > +The ``qemu-system-i386`` binary was mainly useful for running with KVM
> > > > +on 32-bit x86 hosts, but most Linux distributions already removed their
> > > > +support for 32-bit x86 kernels, so hardly anybody still needs this. The
> > > > +``qemu-system-x86_64`` binary is a proper superset and can be used to
> > > > +run 32-bit guests by selecting a 32-bit CPU model, including KVM support
> > > > +on x86_64 hosts. Thus users are recommended to reconfigure their systems
> > > > +to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
> > > > +environment should be enforced, you can switch off the "long mode" CPU
> > > > +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> > > > +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> > > > +disabled.
> > >
> > > Why don't we just have our install rules create the symlink from
> > > qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> > > ongoing maint cost, without need to deprecate stuff / impact users
> >
> > I think we should do that once the deprecation period is over and we don't
> > allow to build QEMU in this mode anymore. I would rather not jump directly
> > to that state to provide people some time for experimenting whether this new
> > approach works as expected in all scenarios that are in use.
>
> This feels a bit wierd as a deprecation though. We're telling people
> not to use qemu-system-i386 and yet we intend to continue providing
> it via a symlink and expect full back compatibility and people can
> carry on with it forever.
>
>
> I think this is probably something better handled via a build time
> option & messages from
>
> * Step 1: full i686 binary by default but have --enable-i686-compat
> to switch to symlink. Issue hint message that symlink will
> become the default in future & asking for feedback if
> --enable-i686-compat is not given
>
> * Step 2: symlink i686 binary by default but have --disable-i686-compat
> to switch to full binary. Issue *WARNING* that full binary
> will be soon removed if --disable-i686-compat is given
>
> * Step 3: remove full binary
Having said that, I guess this should still be expressed in a deprecation
note, if we rephase it to describe this plan.
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 :|
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-02 9:51 [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary Thomas Huth
` (9 preceding siblings ...)
2026-04-02 9:51 ` [PATCH 10/10] docs/about/deprecated: Deprecate the qemu-system-i386 binary Thomas Huth
@ 2026-04-02 11:20 ` Peter Maydell
2026-04-02 13:02 ` Thomas Huth
2026-04-06 4:47 ` Pierrick Bouvier
10 siblings, 2 replies; 22+ messages in thread
From: Peter Maydell @ 2026-04-02 11:20 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, qemu-devel, Pierrick Bouvier, Michael S. Tsirkin,
Richard Henderson, Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
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é
2026-04-06 4:47 ` Pierrick Bouvier
1 sibling, 1 reply; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 13:02 UTC (permalink / raw)
To: Peter Maydell
Cc: Paolo Bonzini, qemu-devel, Pierrick Bouvier, Michael S. Tsirkin,
Richard Henderson, Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-02 13:02 ` Thomas Huth
@ 2026-04-02 16:37 ` Daniel P. Berrangé
2026-04-02 16:44 ` Thomas Huth
0 siblings, 1 reply; 22+ messages in thread
From: Daniel P. Berrangé @ 2026-04-02 16:37 UTC (permalink / raw)
To: Thomas Huth
Cc: Peter Maydell, Paolo Bonzini, qemu-devel, Pierrick Bouvier,
Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
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 :|
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-02 16:37 ` Daniel P. Berrangé
@ 2026-04-02 16:44 ` Thomas Huth
0 siblings, 0 replies; 22+ messages in thread
From: Thomas Huth @ 2026-04-02 16:44 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Peter Maydell, Paolo Bonzini, qemu-devel, Pierrick Bouvier,
Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-02 11:20 ` [PATCH for-11.1 00/10] " Peter Maydell
2026-04-02 13:02 ` Thomas Huth
@ 2026-04-06 4:47 ` Pierrick Bouvier
2026-04-08 7:20 ` Thomas Huth
1 sibling, 1 reply; 22+ messages in thread
From: Pierrick Bouvier @ 2026-04-06 4:47 UTC (permalink / raw)
To: Peter Maydell, Thomas Huth
Cc: Paolo Bonzini, qemu-devel, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-06 4:47 ` Pierrick Bouvier
@ 2026-04-08 7:20 ` Thomas Huth
2026-04-08 15:42 ` Pierrick Bouvier
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Huth @ 2026-04-08 7:20 UTC (permalink / raw)
To: Pierrick Bouvier, Peter Maydell
Cc: Paolo Bonzini, qemu-devel, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH for-11.1 00/10] Deprecate the qemu-system-i386 binary
2026-04-08 7:20 ` Thomas Huth
@ 2026-04-08 15:42 ` Pierrick Bouvier
0 siblings, 0 replies; 22+ messages in thread
From: Pierrick Bouvier @ 2026-04-08 15:42 UTC (permalink / raw)
To: Thomas Huth, Peter Maydell
Cc: Paolo Bonzini, qemu-devel, Michael S. Tsirkin, Richard Henderson,
Philippe Mathieu-Daudé, Zhao Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread