qemu/linux-user/x86_64/target_elf.h

/*
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation, or (at your option) any
 * later version. See the COPYING file in the top-level directory.
 */

#ifndef X86_64_TARGET_ELF_H
#define X86_64_TARGET_ELF_H
static inline const char *cpu_get_model(uint32_t eflags)
{
    return "max";
}
#endif
linux-user: Move CPU type name selection to a function Instead of a sequence of "#if ... #endif" move the selection to a function in linux-user//target_elf.h We can't add them in linux-user//target_cpu.h because we will need to include "elf.h" to use ELF flags with eflags, and including "elf.h" in "target_cpu.h" introduces some conflicts in elfload.c Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180220173307.25125-2-laurent@vivier.eu> 2018-02-20 17:33:04 +00:00			`/*`
			`* This program is free software; you can redistribute it and/or modify`
			`* it under the terms of the GNU General Public License version 2 as`
			`* published by the Free Software Foundation, or (at your option) any`
			`* later version. See the COPYING file in the top-level directory.`
			`*/`

			`#ifndef X86_64_TARGET_ELF_H`
			`#define X86_64_TARGET_ELF_H`
			`static inline const char *cpu_get_model(uint32_t eflags)`
			`{`
linux-user: use 'max' instead of 'qemu32' / 'qemu64' by default 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> 2022-09-23 11:04:13 +00:00			`return "max";`
linux-user: Move CPU type name selection to a function Instead of a sequence of "#if ... #endif" move the selection to a function in linux-user//target_elf.h We can't add them in linux-user//target_cpu.h because we will need to include "elf.h" to use ELF flags with eflags, and including "elf.h" in "target_cpu.h" introduces some conflicts in elfload.c Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180220173307.25125-2-laurent@vivier.eu> 2018-02-20 17:33:04 +00:00			`}`
			`#endif`