File linux-user-use-max-as-default-CPU-model-.patch of Package qemu

From: Dario Faggioli <dfaggioli@suse.com>
Date: Wed, 28 Sep 2022 13:13:08 +0200
Subject: linux-user: use "max" as default CPU model, to deal with x86_64-v2
 binaries

Git-commit: 0000000000000000000000000000000000000000
References: bsc#1203684

The old "qemu64" model cannot run binaries compiled for, e.g.,
x86_64-v2. This could be a problem because a couple of major
distribution are switching to that as their baseline. In fact, errors
like this one can be observed (if 'ls' is such a binary):

  x86_64-linux-user/qemu-x86_64 /usr/bin/ls
  qemu: uncaught target signal 4 (Illegal instruction) - core dumped

Instead, using "max" as the CPU model, everything (of course) works:

  export QEMU_CPU=max
  x86_64-linux-user/qemu-x86_64 /usr/bin/ls

This has been and is being discussed in several places, e.g.:
https://lore.kernel.org/qemu-devel/20210607135843.196595-1-berrange@redhat.com/
https://bugzilla.redhat.com/show_bug.cgi?id=2079915
https://bugzilla.redhat.com/show_bug.cgi?id=2080133
http:s//github.com/containers/podman/issues/14314

However, these are all about system-emulation/virtualization, which is
indeed quite tricky. In fact, what would be a good alternative default
CPU model to pick, in that case? At the same time, however, it's also
less problematic. In fact, people using QEMU for that purpose are likely
in one of the following two situations already:
1) they're starting QEMU manually, with a long and complex command line,
   for whatever specific reason. In that case, adding '-cpu host' (or
   whatever) to such long and complex command line, isn't a big deal;
2) they're using QEMU via libvirt, which has its own fancy and
   convenient ways of determining the best CPU model, and the default
   "qemu64" one is pretty much never being used.

The case of Linux user emulation, however, it's a bit more tricky, as
it's less convenient to actually pass any parameter to QEMU at all, in
this scenario, so having to add one might be complicated. The same goes
for having to define the QEMU_CPU environment variable. When doing Linux
userspace emulation, though, a lot of the downsides of just using '-cpu
host' as the default are non-issue (e.g., we do not need to think about
migration!).

Therefore, while the topic remain complex and unsolved for system
emulation, for Linux user, let's just switch and be happy.

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
 linux-user/x86_64/target_elf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/x86_64/target_elf.h b/linux-user/x86_64/target_elf.h
index 7b76a90de8805a84b4983f3b2bb9..3f628f8d66197faae698cbec4e24 100644
--- a/linux-user/x86_64/target_elf.h
+++ b/linux-user/x86_64/target_elf.h
@@ -9,6 +9,6 @@
 #define X86_64_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
-    return "qemu64";
+    return "max";
 }
 #endif