[RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Thomas Huth]

Allow running qemu-system-x86_64 in 32-bit-only mode (by renaming
or symlinking the binary to "qemu-system-i386"). After doing this,
qemu-system-x86_64 should be a proper superset of qemu-system-i386
(apart from 32-bit KVM support, which however is not really required
anymore, see https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/ ).
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.

Marked as RFC since there are likely still a bunch of spots around
that need attention, e.g.:

- CPU types have different suffixes between the -x86_64 and -i386
  variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
  about this in the new qemu-system-i386 symlink run mode?

- The code in target/i386/tcg/sysemu/smm_helper.c looks like it
  maybe needs a runtime switch, too ... or is it ok to leave this
  hard-coded to the x86_64 version?

Anyway, I'd like to get some feedback on this idea here... What
do you think of the idea of getting rid of the qemu-system-i386
binary this way in the future?

Thomas Huth (3):
  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
  docs/about/deprecated: Deprecate the qemu-system-i386 binary

 docs/about/deprecated.rst | 16 ++++++++++++++++
 include/hw/core/cpu.h     | 10 ++++++++++
 target/i386/cpu.h         |  4 ++--
 cpu.c                     | 13 +++++++++++++
 softmmu/vl.c              |  1 +
 target/i386/cpu.c         | 28 +++++++++++++---------------
 target/i386/gdbstub.c     |  8 +-------
 7 files changed, 56 insertions(+), 24 deletions(-)

-- 
2.31.1

[RFC PATCH 1/3] cpu: Add a way to detect 32-bit mode from argv0

[Thomas Huth]

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/hw/core/cpu.h | 10 ++++++++++
 cpu.c                 | 13 +++++++++++++
 softmmu/vl.c          |  1 +
 3 files changed, 24 insertions(+)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index 397fd3ac68..8fc15b7797 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -470,6 +470,15 @@ extern __thread CPUState *current_cpu;
 extern bool mttcg_enabled;
 #define qemu_tcg_mttcg_enabled() (mttcg_enabled)
 
+/**
+ * qemu_target_only_32bits:
+ * Check whether the target is 32 bits only (like i386 in contrast to x86_64).
+ *
+ * Returns: %true if we are running with a 32-bit only target
+ */
+extern bool target_only_32bits;
+#define qemu_target_only_32bits() (target_only_32bits)
+
 /**
  * cpu_paging_enabled:
  * @cpu: The CPU whose state is to be inspected.
@@ -1009,6 +1018,7 @@ void cpu_exec_unrealizefn(CPUState *cpu);
  */
 bool target_words_bigendian(void);
 
+void cpu_init_target_only_32bits(const char *argv0);
 void page_size_init(void);
 
 #ifdef NEED_CPU_H
diff --git a/cpu.c b/cpu.c
index 9105c85404..0b498f3a53 100644
--- a/cpu.c
+++ b/cpu.c
@@ -47,6 +47,8 @@
 uintptr_t qemu_host_page_size;
 intptr_t qemu_host_page_mask;
 
+bool target_only_32bits = (TARGET_LONG_BITS == 32);
+
 #ifndef CONFIG_USER_ONLY
 static int cpu_common_post_load(void *opaque, int version_id)
 {
@@ -427,6 +429,17 @@ bool target_words_bigendian(void)
 #endif
 }
 
+/*
+ * This is used for 64-bit targets that can also run in restricted 32-bit
+ * mode, e.g. if running as qemu-system-i386 instead of qemu-system-x86_64
+ */
+void cpu_init_target_only_32bits(const char *argv0)
+{
+    target_only_32bits |= g_str_has_suffix(argv0, "-i386") ||
+                          g_str_has_suffix(argv0, "-arm") ||
+                          g_str_has_suffix(argv0, "-ppc");
+}
+
 void page_size_init(void)
 {
     /* NOTE: we can always suppose that qemu_host_page_size >=
diff --git a/softmmu/vl.c b/softmmu/vl.c
index fb6c221e8e..51b35a6f0b 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2677,6 +2677,7 @@ void qemu_init(int argc, char **argv)
 
     error_init(argv[0]);
     qemu_init_exec_dir(argv[0]);
+    cpu_init_target_only_32bits(argv[0]);
 
     qemu_init_arch_modules();
 
-- 
2.31.1

[RFC PATCH 2/3] target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only

[Thomas Huth]

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.
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     |  4 ++--
 target/i386/cpu.c     | 28 +++++++++++++---------------
 target/i386/gdbstub.c |  8 +-------
 3 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d243e290d3..5cb2eb3493 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -40,8 +40,8 @@
 #define TARGET_HAS_PRECISE_SMC
 
 #ifdef TARGET_X86_64
-#define I386_ELF_MACHINE  EM_X86_64
-#define ELF_MACHINE_UNAME "x86_64"
+#define I386_ELF_MACHINE  (qemu_target_only_32bits() ? EM_386 : EM_X86_64)
+#define ELF_MACHINE_UNAME (qemu_target_only_32bits() ? "i686" : "x86_64")
 #else
 #define I386_ELF_MACHINE  EM_386
 #define ELF_MACHINE_UNAME "i686"
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 2e30e348a1..f713005476 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5093,11 +5093,9 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
     } else {
         return ~0;
     }
-#ifndef TARGET_X86_64
-    if (w == FEAT_8000_0001_EDX) {
+    if (qemu_target_only_32bits() && w == FEAT_8000_0001_EDX) {
         r &= ~CPUID_EXT2_LM;
     }
-#endif
     if (migratable_only) {
         r &= x86_cpu_get_migratable_flags(w);
     }
@@ -5267,11 +5265,11 @@ static void x86_cpu_load_model(X86CPU *cpu, X86CPUModel *model)
 
 static gchar *x86_gdb_arch_name(CPUState *cs)
 {
-#ifdef TARGET_X86_64
-    return g_strdup("i386:x86-64");
-#else
-    return g_strdup("i386");
-#endif
+    if (qemu_target_only_32bits()) {
+        return g_strdup("i386");
+    } else {
+        return g_strdup("i386:x86-64");
+    }
 }
 
 static void x86_cpu_cpudef_class_init(ObjectClass *oc, void *data)
@@ -7295,13 +7293,13 @@ static void x86_cpu_common_class_init(ObjectClass *oc, void *data)
 #endif /* !CONFIG_USER_ONLY */
 
     cc->gdb_arch_name = x86_gdb_arch_name;
-#ifdef TARGET_X86_64
-    cc->gdb_core_xml_file = "i386-64bit.xml";
-    cc->gdb_num_core_regs = 66;
-#else
-    cc->gdb_core_xml_file = "i386-32bit.xml";
-    cc->gdb_num_core_regs = 50;
-#endif
+    if (qemu_target_only_32bits()) {
+        cc->gdb_core_xml_file = "i386-32bit.xml";
+        cc->gdb_num_core_regs = 50;
+    } else {
+        cc->gdb_core_xml_file = "i386-64bit.xml";
+        cc->gdb_num_core_regs = 66;
+    }
     cc->disas_set_info = x86_disas_set_info;
 
     dc->user_creatable = true;
diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
index ebb000df6a..35a56b317c 100644
--- a/target/i386/gdbstub.c
+++ b/target/i386/gdbstub.c
@@ -72,15 +72,9 @@ static const int gpr_map32[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
 #define IDX_CTL_CR8_REG     (IDX_CTL_REGS + 4)
 #define IDX_CTL_EFER_REG    (IDX_CTL_REGS + 5)
 
-#ifdef TARGET_X86_64
-#define GDB_FORCE_64 1
-#else
-#define GDB_FORCE_64 0
-#endif
-
 static int gdb_read_reg_cs64(uint32_t hflags, GByteArray *buf, target_ulong val)
 {
-    if ((hflags & HF_CS64_MASK) || GDB_FORCE_64) {
+    if ((hflags & HF_CS64_MASK) || !qemu_target_only_32bits()) {
         return gdb_get_reg64(buf, val);
     }
     return gdb_get_reg32(buf, val);
-- 
2.31.1

[RFC PATCH 3/3] docs/about/deprecated: Deprecate the qemu-system-i386 binary

[Thomas Huth]

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 deprecated 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/

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 docs/about/deprecated.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 1ca9dc33d6..c205816c7d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -34,6 +34,22 @@ deprecating the build option and no longer defend it in CI. The
 ``--enable-gcov`` build option remains for analysis test case
 coverage.
 
+``qemu-system-i386`` binary (since 8.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.
+
+
 System emulator command line arguments
 --------------------------------------
 
-- 
2.31.1

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Paolo Bonzini]

On 4/25/23 15:38, Thomas Huth wrote:
> - CPU types have different suffixes between the -x86_64 and -i386
>    variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
>    about this in the new qemu-system-i386 symlink run mode?
> 
> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it
>    maybe needs a runtime switch, too ... or is it ok to leave this
>    hard-coded to the x86_64 version?

Yes, it would have to switch based on the CPU's LM feature.

> Anyway, I'd like to get some feedback on this idea here... What
> do you think of the idea of getting rid of the qemu-system-i386
> binary this way in the future?

I wonder if we should take this a step further and rename 
qemu-system-x86_64 to qemu-system-x86!  Distros can if they wish create 
symlinks to both qemu-system-i386 and qemu-system-x86_64.

Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 and, 
if they don't have LM set, to foo-i386 as well.

Paolo

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Thomas Huth]

On 26/04/2023 12.59, Paolo Bonzini wrote:
> On 4/25/23 15:38, Thomas Huth wrote:
>> - CPU types have different suffixes between the -x86_64 and -i386
>>    variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
>>    about this in the new qemu-system-i386 symlink run mode?
>>
>> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it
>>    maybe needs a runtime switch, too ... or is it ok to leave this
>>    hard-coded to the x86_64 version?
> 
> Yes, it would have to switch based on the CPU's LM feature.

Ok. BTW, what happens if you run qemu-system-x86_64 with -cpu lm=off today? 
Isn't that a problem already?

>> Anyway, I'd like to get some feedback on this idea here... What
>> do you think of the idea of getting rid of the qemu-system-i386
>> binary this way in the future?
> 
> I wonder if we should take this a step further and rename qemu-system-x86_64 
> to qemu-system-x86!  Distros can if they wish create symlinks to both 
> qemu-system-i386 and qemu-system-x86_64.
> 
> Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 and, if 
> they don't have LM set, to foo-i386 as well.

I like the idea! ... we could maybe even go a step further and change the 
default machine to "q35" in the -x86 binary (or use no default machine at 
all), and switch back to "pc" as default if running in -x86_64 or -i386 mode...

  Thomas

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Paolo Bonzini]

On 4/27/23 10:13, Thomas Huth wrote:
> On 26/04/2023 12.59, Paolo Bonzini wrote:
>> On 4/25/23 15:38, Thomas Huth wrote:
>>> - CPU types have different suffixes between the -x86_64 and -i386
>>>    variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
>>>    about this in the new qemu-system-i386 symlink run mode?
>>>
>>> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it
>>>    maybe needs a runtime switch, too ... or is it ok to leave this
>>>    hard-coded to the x86_64 version?
>>
>> Yes, it would have to switch based on the CPU's LM feature.
> 
> Ok. BTW, what happens if you run qemu-system-x86_64 with -cpu lm=off 
> today? Isn't that a problem already?

Nothing special---I was thinking of migration compatibility from old 
savefiles created with qemu-system-i386, but using LM would break 
compatibility from old savefiles created with qemu-system-x86_64 and 
32-bit CPU models.

A better way to go would be to have a separate property than LM (e.g. 
64bit-smm-format=on|off), and add a "-global" based on -i386 vs. -x86_64.

>>> Anyway, I'd like to get some feedback on this idea here... What
>>> do you think of the idea of getting rid of the qemu-system-i386
>>> binary this way in the future?
>>
>> I wonder if we should take this a step further and rename 
>> qemu-system-x86_64 to qemu-system-x86!  Distros can if they wish 
>> create symlinks to both qemu-system-i386 and qemu-system-x86_64.
>>
>> Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 
>> and, if they don't have LM set, to foo-i386 as well.
> 
> I like the idea! ... we could maybe even go a step further and change 
> the default machine to "q35" in the -x86 binary (or use no default 
> machine at all), and switch back to "pc" as default if running in 
> -x86_64 or -i386 mode...

That's a clever way to move away from the "-M pc" default, indeed.

(BTW, on the user-mode emulation side qemu-i386 and qemu-x86_64 identify 
the ABI, so the binaries cannot be unified.  Still, it would be 
beneficial to make qemu-i386 use the x86_64 emulation code, because 
right now QEMU user-mode emulation---unlike real hardware---cannot run 
32-bit binaries with new CPU models.  So the above unification effort 
would benefit both system and user-mode emulators).

Paolo

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Daniel P. Berrangé]

On Wed, Apr 26, 2023 at 12:59:13PM +0200, Paolo Bonzini wrote:
> On 4/25/23 15:38, Thomas Huth wrote:
> > - CPU types have different suffixes between the -x86_64 and -i386
> >    variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
> >    about this in the new qemu-system-i386 symlink run mode?
> > 
> > - The code in target/i386/tcg/sysemu/smm_helper.c looks like it
> >    maybe needs a runtime switch, too ... or is it ok to leave this
> >    hard-coded to the x86_64 version?
> 
> Yes, it would have to switch based on the CPU's LM feature.
> 
> > Anyway, I'd like to get some feedback on this idea here... What
> > do you think of the idea of getting rid of the qemu-system-i386
> > binary this way in the future?
> 
> I wonder if we should take this a step further and rename qemu-system-x86_64
> to qemu-system-x86!  Distros can if they wish create symlinks to both
> qemu-system-i386 and qemu-system-x86_64.

I can't help feeling this just creates a new upgrade burden for distros
for no obvious win.

Things have gone quite recently, but if we introduce next-generation
QEMU system emulator binary which is 100% QMP based, I think that would
be the ideal time to change naming convention to -x86

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Paolo Bonzini]

On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > I wonder if we should take this a step further and rename qemu-system-x86_64
> > to qemu-system-x86!  Distros can if they wish create symlinks to both
> > qemu-system-i386 and qemu-system-x86_64.
>
> I can't help feeling this just creates a new upgrade burden for distros
> for no obvious win.

We can create the symlinks on install as well during the deprecation
period. It doesn't have to be done by distros.

For me, the main benefit of implementing -x86 for system emulation is
that we need to move user-mode emulation to the x86_64 backend anyway.
And the less difference between the two emulation scenarios, the
better.

Paolo

> Things have gone quite recently, but if we introduce next-generation
> QEMU system emulator binary which is 100% QMP based, I think that would
> be the ideal time to change naming convention to -x86
>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Daniel P. Berrangé]

On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > I wonder if we should take this a step further and rename qemu-system-x86_64
> > > to qemu-system-x86!  Distros can if they wish create symlinks to both
> > > qemu-system-i386 and qemu-system-x86_64.
> >
> > I can't help feeling this just creates a new upgrade burden for distros
> > for no obvious win.
> 
> We can create the symlinks on install as well during the deprecation
> period. It doesn't have to be done by distros.

What's the actual win though ?  Why would anyone want to create guests
using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
still exist indefinitely for backwards compat.  What does having a
qemu-system-x86 add that can't be achieve just though hardlink
between the two existing binaries ?

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Paolo Bonzini]

On 4/27/23 10:33, Daniel P. Berrangé wrote:
> On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
>> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> I wonder if we should take this a step further and rename qemu-system-x86_64
>>>> to qemu-system-x86!  Distros can if they wish create symlinks to both
>>>> qemu-system-i386 and qemu-system-x86_64.
>>>
>>> I can't help feeling this just creates a new upgrade burden for distros
>>> for no obvious win.
>>
>> We can create the symlinks on install as well during the deprecation
>> period. It doesn't have to be done by distros.
> 
> What's the actual win though ?  Why would anyone want to create guests
> using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
> still exist indefinitely for backwards compat.  What does having a
> qemu-system-x86 add that can't be achieve just though hardlink
> between the two existing binaries ?

That the two existing binaries can also be removed sooner or later.

Even if we add a QMP-only binary, qemu-system-* would be a nicer 
interface for developers and for quick-and-dirty launch of guests 
(including usecases such as kvm-unit-tests).  Libvirt is not even 
available on Windows and I think on any non-Linux system?  So having a 
qemu-system-x86 that has the same defaults as qemu-qmp-x86 is useful for 
developers.

That said, most people are really using qemu-kvm and not 
qemu-system-{i386,x86_64}.  On one hand it'd be nice if qemu-kvm's 
default machine type changed away from "-M pc", on the other hand that 
would have consequences on CLI backwards-compatibility. :(

Paolo

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Thomas Huth]

On 27/04/2023 10.33, Daniel P. Berrangé wrote:
> On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
>> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> I wonder if we should take this a step further and rename qemu-system-x86_64
>>>> to qemu-system-x86!  Distros can if they wish create symlinks to both
>>>> qemu-system-i386 and qemu-system-x86_64.
>>>
>>> I can't help feeling this just creates a new upgrade burden for distros
>>> for no obvious win.
>>
>> We can create the symlinks on install as well during the deprecation
>> period. It doesn't have to be done by distros.
> 
> What's the actual win though ?  Why would anyone want to create guests
> using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
> still exist indefinitely for backwards compat.

We could deprecate the old wrappers at one point in time, so we would 
finally have a cleaner interface.

>  What does having a
> qemu-system-x86 add that can't be achieve just though hardlink
> between the two existing binaries ?

We'd finally have a binary with saner default settings compared to the 
backlevel "pc" machine type that we have as a default now?

  Thomas

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Daniel P. Berrangé]

On Thu, Apr 27, 2023 at 02:12:59PM +0200, Thomas Huth wrote:
> On 27/04/2023 10.33, Daniel P. Berrangé wrote:
> > On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
> > > On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > > I wonder if we should take this a step further and rename qemu-system-x86_64
> > > > > to qemu-system-x86!  Distros can if they wish create symlinks to both
> > > > > qemu-system-i386 and qemu-system-x86_64.
> > > > 
> > > > I can't help feeling this just creates a new upgrade burden for distros
> > > > for no obvious win.
> > > 
> > > We can create the symlinks on install as well during the deprecation
> > > period. It doesn't have to be done by distros.
> > 
> > What's the actual win though ?  Why would anyone want to create guests
> > using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
> > still exist indefinitely for backwards compat.
> 
> We could deprecate the old wrappers at one point in time, so we would
> finally have a cleaner interface.

At the cost of breaking compat every single script and doc that
referrs to the historical binaries.

I think incompatible changes are worth it, but only if we associate
them with the a approach to qemu system emulator binaries, as that's
where we'll get a compelling benefit. Fiddling around with the
existing binaries is creating pain for little gain IMHO.

> >  What does having a
> > qemu-system-x86 add that can't be achieve just though hardlink
> > between the two existing binaries ?
> 
> We'd finally have a binary with saner default settings compared to the
> backlevel "pc" machine type that we have as a default now?

On the libvirt side we would have to ensure there was no change in
defaults regardles of what he QEMU binary did.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH 3/3] docs/about/deprecated: Deprecate the qemu-system-i386 binary

[Philippe Mathieu-Daudé]

On 25/4/23 15:38, Thomas Huth wrote:
> 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 deprecated 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/
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

> ---
>   docs/about/deprecated.rst | 16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 1ca9dc33d6..c205816c7d 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -34,6 +34,22 @@ deprecating the build option and no longer defend it in CI. The
>   ``--enable-gcov`` build option remains for analysis test case
>   coverage.
>   
> +``qemu-system-i386`` binary (since 8.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.
> +
> +
>   System emulator command line arguments
>   --------------------------------------
>   

Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Philippe Mathieu-Daudé]

On 26/4/23 12:59, Paolo Bonzini wrote:
> On 4/25/23 15:38, Thomas Huth wrote:
>> - CPU types have different suffixes between the -x86_64 and -i386
>>    variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care
>>    about this in the new qemu-system-i386 symlink run mode?
>>
>> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it
>>    maybe needs a runtime switch, too ... or is it ok to leave this
>>    hard-coded to the x86_64 version?
> 
> Yes, it would have to switch based on the CPU's LM feature.
> 
>> Anyway, I'd like to get some feedback on this idea here... What
>> do you think of the idea of getting rid of the qemu-system-i386
>> binary this way in the future?
> 
> I wonder if we should take this a step further and rename 
> qemu-system-x86_64 to qemu-system-x86!  Distros can if they wish create 
> symlinks to both qemu-system-i386 and qemu-system-x86_64.

Is it simpler to *add* an experimental qemu-system-x86 binary, then
once it support both i386/x86_64 modes, remove (symlinking) the other
ones, or rename qemu-system-x86_64 and start with a symlink?
(I know we are very reluctant to add new binaries due to distributions
shipping them even if experimental).

> Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 and, 
> if they don't have LM set, to foo-i386 as well.
> 
> Paolo
>