From: Laurent Vivier <laurent@vivier.eu>
To: qemu-devel@nongnu.org
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Laurent Vivier" <laurent@vivier.eu>
Subject: [PULL 01/37] linux-user: use 'max' instead of 'qemu32' / 'qemu64' by default
Date: Wed, 28 Sep 2022 22:27:01 +0200 [thread overview]
Message-ID: <20220928202737.793171-2-laurent@vivier.eu> (raw)
In-Reply-To: <20220928202737.793171-1-laurent@vivier.eu>
From: Daniel P. Berrangé <berrange@redhat.com>
The 'qemu64' CPU model implements the least featureful x86_64 CPU that's
possible. Historically this hasn't been an issue since it was rare for
OS distros to build with a higher mandatory CPU baseline.
With RHEL-9, however, the entire distro is built for the x86_64-v2 ABI
baseline:
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
It is likely that other distros may take similar steps in the not too
distant future. For example, it has been suggested for Fedora on a
number of occasions.
This new baseline is not compatible with the qemu64 CPU model though.
While it is possible to pass a '-cpu xxx' flag to qemu-x86_64, the
usage of QEMU doesn't always allow for this. For example, the args
are typically controlled via binfmt rules that the user has no ability
to change. This impacts users who are trying to use podman on aarch64
platforms, to run containers with x86_64 content. There's no arg to
podman that can be used to change the qemu-x86_64 args, and a non-root
user of podman can not change binfmt rules without elevating privileges:
https://github.com/containers/podman/issues/15456#issuecomment-1228210973
Changing to the 'max' CPU model gives 'qemu-x86_64' maximum
compatibility with binaries it is likely to encounter in the wild,
and not likely to have a significant downside for existing usage.
Most other architectures already use an 'any' CPU model, which is
often mapped to 'max' (or similar) already, rather than the oldest
possible CPU model.
For the sake of consistency the 'i386' architecture is also changed
from using 'qemu32' to 'max'.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220923110413.70593-1-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
---
linux-user/i386/target_elf.h | 2 +-
linux-user/x86_64/target_elf.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/i386/target_elf.h b/linux-user/i386/target_elf.h
index 1c6142e7da0d..238a9aba738a 100644
--- a/linux-user/i386/target_elf.h
+++ b/linux-user/i386/target_elf.h
@@ -9,6 +9,6 @@
#define I386_TARGET_ELF_H
static inline const char *cpu_get_model(uint32_t eflags)
{
- return "qemu32";
+ return "max";
}
#endif
diff --git a/linux-user/x86_64/target_elf.h b/linux-user/x86_64/target_elf.h
index 7b76a90de880..3f628f8d6619 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
--
2.37.3
next prev parent reply other threads:[~2022-09-28 20:49 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 20:27 [PULL 00/37] Linux user for 7.2 patches Laurent Vivier
2022-09-28 20:27 ` Laurent Vivier [this message]
2022-09-28 20:27 ` [PULL 02/37] linux-user: fix readlinkat handling with magic exe symlink Laurent Vivier
2022-09-28 20:27 ` [PULL 03/37] linux-user: Add missing signals in strace output Laurent Vivier
2022-09-28 20:27 ` [PULL 04/37] linux-user: Add missing clock_gettime64() syscall strace Laurent Vivier
2022-09-28 20:27 ` [PULL 05/37] linux-user: Add pidfd_open(), pidfd_send_signal() and pidfd_getfd() syscalls Laurent Vivier
2022-09-28 20:27 ` [PULL 06/37] linux-user: Log failing executable in EXCP_DUMP() Laurent Vivier
2022-09-28 20:27 ` [PULL 07/37] linux-user/hppa: Use EXCP_DUMP() to show enhanced debug info Laurent Vivier
2022-09-28 20:27 ` [PULL 08/37] linux-user/hppa: Dump IIR on register dump Laurent Vivier
2022-09-28 20:27 ` [PULL 09/37] linux-user: Fix strace of chmod() if mode == 0 Laurent Vivier
2022-09-28 20:27 ` [PULL 10/37] linux-user/hppa: Set TASK_UNMAPPED_BASE to 0xfa000000 for hppa arch Laurent Vivier
2022-09-28 20:27 ` [PULL 11/37] linux-user: Add strace for clock_nanosleep() Laurent Vivier
2022-09-28 20:27 ` [PULL 12/37] linux-user: Show timespec on strace for futex() Laurent Vivier
2022-09-28 20:27 ` [PULL 13/37] linux-user: Provide MADV_* definitions Laurent Vivier
2022-09-28 20:27 ` [PULL 14/37] linux-user: Fix madvise(MADV_DONTNEED) on alpha Laurent Vivier
2022-09-28 20:27 ` [PULL 15/37] linux-user: Implement stracing madvise() Laurent Vivier
2022-09-28 20:27 ` [PULL 16/37] linux-user: Passthrough MADV_DONTNEED for certain file mappings Laurent Vivier
2022-09-28 20:27 ` [PULL 17/37] tests/tcg/linux-test: Add linux-madvise test Laurent Vivier
2022-09-28 20:27 ` [PULL 18/37] linux-user: Fix TARGET_PROT_SEM for XTENSA Laurent Vivier
2022-09-28 20:27 ` [PULL 19/37] linux-user: Add proper strace format strings for getdents()/getdents64() Laurent Vivier
2022-09-28 20:27 ` [PULL 20/37] linux-user/hppa: Add signal trampoline for hppa target Laurent Vivier
2022-09-28 20:27 ` [PULL 21/37] linux-user/hppa: Drop stack guard page on " Laurent Vivier
2022-09-28 20:27 ` [PULL 22/37] linux-user/hppa: Increase guest stack size to 80MB for " Laurent Vivier
2022-09-28 20:27 ` [PULL 23/37] linux-user/hppa: Allow PROT_GROWSUP and PROT_GROWSDOWN in mprotect() Laurent Vivier
2022-09-28 20:27 ` [PULL 24/37] linux-user/hppa: Fix setup_sigcontext() Laurent Vivier
2022-09-28 20:27 ` [PULL 25/37] linux-user: fix bug about missing signum convert of sigqueue Laurent Vivier
2022-09-28 20:27 ` [PULL 26/37] linux-user: Don't assume 0 is not a valid host timer_t value Laurent Vivier
2022-09-28 20:27 ` [PULL 27/37] linux-user/s390x: Save/restore fpc when handling a signal Laurent Vivier
2022-09-28 20:27 ` [PULL 28/37] linux-user: Introduce stubs for ELF AT_BASE_PLATFORM Laurent Vivier
2022-09-28 20:27 ` [PULL 29/37] linux-user: Set ELF_BASE_PLATFORM for MIPS Laurent Vivier
2022-09-28 20:27 ` [PULL 30/37] linux-user: Combine do_futex and do_futex_time64 Laurent Vivier
2022-09-28 20:27 ` [PULL 31/37] linux-user: Sink call to do_safe_futex Laurent Vivier
2022-09-28 20:27 ` [PULL 32/37] linux-user: Implement FUTEX_WAKE_BITSET Laurent Vivier
2022-09-28 20:27 ` [PULL 33/37] linux-user: Convert signal number for FUTEX_FD Laurent Vivier
2022-09-28 20:27 ` [PULL 34/37] linux-user: Implement PI futexes Laurent Vivier
2022-09-28 20:27 ` [PULL 35/37] linux-user: Update print_futex_op Laurent Vivier
2022-09-28 20:27 ` [PULL 36/37] linux-user: Lock log around strace Laurent Vivier
2022-09-28 20:27 ` [PULL 37/37] linux-user: Add parameters of getrandom() syscall for strace Laurent Vivier
2022-09-29 14:48 ` [PULL 00/37] Linux user for 7.2 patches Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220928202737.793171-2-laurent@vivier.eu \
--to=laurent@vivier.eu \
--cc=berrange@redhat.com \
--cc=f4bug@amsat.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).