Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
home:regataos
qemu
linux-user-use-max-as-default-CPU-model-.patch
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
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
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor