aboutsummaryrefslogtreecommitdiff
path: root/target/i386/cpu.c
AgeCommit message (Collapse)Author
2023-11-17target/i386/cpu: Improve error message for property "vendor"Markus Armbruster
Improve $ qemu-system-x86_64 -device max-x86_64-cpu,vendor=me qemu-system-x86_64: -device max-x86_64-cpu,vendor=me: Property '.vendor' doesn't take value 'me' to qemu-system-x86_64: -device max-x86_64-cpu,vendor=0123456789abc: value of property 'vendor' must consist of exactly 12 characters Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231031111059.3407803-8-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> [Typo corrected]
2023-11-07system/cpus: Fix CPUState.nr_cores' calculationZhuocheng Ding
From CPUState.nr_cores' comment, it represents "number of cores within this CPU package". After 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology"), the meaning of smp.cores changed to "the number of cores in one die", but this commit missed to change CPUState.nr_cores' calculation, so that CPUState.nr_cores became wrong and now it misses to consider numbers of clusters and dies. At present, only i386 is using CPUState.nr_cores. But as for i386, which supports die level, the uses of CPUState.nr_cores are very confusing: Early uses are based on the meaning of "cores per package" (before die is introduced into i386), and later uses are based on "cores per die" (after die's introduction). This difference is due to that commit a94e1428991f ("target/i386: Add CPUID.1F generation support for multi-dies PCMachine") misunderstood that CPUState.nr_cores means "cores per die" when calculated CPUID.1FH.01H:EBX. After that, the changes in i386 all followed this wrong understanding. With the influence of 003f230e37d7 and a94e1428991f, for i386 currently the result of CPUState.nr_cores is "cores per die", thus the original uses of CPUState.cores based on the meaning of "cores per package" are wrong when multiple dies exist: 1. In cpu_x86_cpuid() of target/i386/cpu.c, CPUID.01H:EBX[bits 23:16] is incorrect because it expects "cpus per package" but now the result is "cpus per die". 2. In cpu_x86_cpuid() of target/i386/cpu.c, for all leaves of CPUID.04H: EAX[bits 31:26] is incorrect because they expect "cpus per package" but now the result is "cpus per die". The error not only impacts the EAX calculation in cache_info_passthrough case, but also impacts other cases of setting cache topology for Intel CPU according to cpu topology (specifically, the incoming parameter "num_cores" expects "cores per package" in encode_cache_cpuid4()). 3. In cpu_x86_cpuid() of target/i386/cpu.c, CPUID.0BH.01H:EBX[bits 15:00] is incorrect because the EBX of 0BH.01H (core level) expects "cpus per package", which may be different with 1FH.01H (The reason is 1FH can support more levels. For QEMU, 1FH also supports die, 1FH.01H:EBX[bits 15:00] expects "cpus per die"). 4. In cpu_x86_cpuid() of target/i386/cpu.c, when CPUID.80000001H is calculated, here "cpus per package" is expected to be checked, but in fact, now it checks "cpus per die". Though "cpus per die" also works for this code logic, this isn't consistent with AMD's APM. 5. In cpu_x86_cpuid() of target/i386/cpu.c, CPUID.80000008H:ECX expects "cpus per package" but it obtains "cpus per die". 6. In simulate_rdmsr() of target/i386/hvf/x86_emu.c, in kvm_rdmsr_core_thread_count() of target/i386/kvm/kvm.c, and in helper_rdmsr() of target/i386/tcg/sysemu/misc_helper.c, MSR_CORE_THREAD_COUNT expects "cpus per package" and "cores per package", but in these functions, it obtains "cpus per die" and "cores per die". On the other hand, these uses are correct now (they are added in/after a94e1428991f): 1. In cpu_x86_cpuid() of target/i386/cpu.c, topo_info.cores_per_die meets the actual meaning of CPUState.nr_cores ("cores per die"). 2. In cpu_x86_cpuid() of target/i386/cpu.c, vcpus_per_socket (in CPUID. 04H's calculation) considers number of dies, so it's correct. 3. In cpu_x86_cpuid() of target/i386/cpu.c, CPUID.1FH.01H:EBX[bits 15:00] needs "cpus per die" and it gets the correct result, and CPUID.1FH.02H:EBX[bits 15:00] gets correct "cpus per package". When CPUState.nr_cores is correctly changed to "cores per package" again , the above errors will be fixed without extra work, but the "currently" correct cases will go wrong and need special handling to pass correct "cpus/cores per die" they want. Fix CPUState.nr_cores' calculation to fit the original meaning "cores per package", as well as changing calculation of topo_info.cores_per_die, vcpus_per_socket and CPUID.1FH. Fixes: a94e1428991f ("target/i386: Add CPUID.1F generation support for multi-dies PCMachine") Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com> Co-developed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231024090323.1859210-4-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-10-25target/i386: check CPUID_PAE to determine 36 bit processor address spaceAni Sinha
PAE mode in x86 supports 36 bit address space. Check the PAE CPUID on the guest processor and set phys_bits to 36 if PAE feature is set. This is in addition to checking the presence of PSE36 CPUID feature for setting 36 bit phys_bits. Signed-off-by: Ani Sinha <anisinha@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20230912120650.371781-1-anisinha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-25target/i386: implement SHA instructionsPaolo Bonzini
The implementation was validated with OpenSSL and with the test vectors in https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/src/x86/sha.rs. The instructions provide a ~25% improvement on hashing a 64 MiB file: runtime goes down from 1.8 seconds to 1.4 seconds; instruction count on the host goes down from 5.8 billion to 4.8 billion with slightly better IPC too. Good job Intel. ;) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-17target/i386/cpu: Fix CPUID_HT exposureXiaoyao Li
When explicitly booting a multiple vcpus vm with "-cpu +ht", it gets warning of warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] Make CPUID_HT as supported unconditionally can resolve the warning. However it introduces another issue that it also expose CPUID_HT to guest when "-cpu host/max" with only 1 vcpu. To fix this, need mark CPUID_HT as the no_autoenable_flags. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20231010060539.210258-1-xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-11hw/core/cpu: Return static value with gdb_arch_name()Akihiko Odaki
All implementations of gdb_arch_name() returns dynamic duplicates of static strings. It's also unlikely that there will be an implementation of gdb_arch_name() that returns a truly dynamic value due to the nature of the function returning a well-known identifiers. Qualify the value gdb_arch_name() with const and make all of its implementations return static strings. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230912224107.29669-8-akihiko.odaki@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-15-alex.bennee@linaro.org>
2023-10-07target/i386: Check for USER_ONLY definition instead of SOFTMMU onePhilippe Mathieu-Daudé
Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one. (target/ was cleaned from invalid CONFIG_SOFTMMU uses at commit cab35c73be, but these files were merged few days after, thus missed the cleanup.) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004082239.27251-1-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-07sysemu/kvm: Restrict hvf_get_supported_cpuid() to x86 targetsPhilippe Mathieu-Daudé
hvf_get_supported_cpuid() is only defined for x86 targets (in target/i386/hvf/x86_cpuid.c). Its declaration is pointless on all other targets. All the calls to it in target/i386/cpu.c are guarded by a call on hvf_enabled(), so are elided when HVF is not built in. Therefore we can remove the unnecessary function stub. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004092510.39498-3-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-04accel/tcg: Remove cpu_set_cpustate_pointersRichard Henderson
This function is now empty, so remove it. In the case of m68k and tricore, this empties the class instance initfn, so remove those as well. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03target/*: Add instance_align to all cpu base classesRichard Henderson
The omission of alignment has technically been wrong since 269bd5d8f61, where QEMU_ALIGNED was added to CPUTLBDescFast. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-09-26target/i386/cpu: avoid shadowed local variablesPaolo Bonzini
Reuse the pointer variable used for the unversioned model. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-25Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingStefan Hajnoczi
* add host ticks function for RISC-V * target/i386: Export GDS_NO bit * target/i386: add support for bit 56 of MSR_IA32_VMX_BASIC * first part of audiodev cleanups # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmUNtYUUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroN7Uwf9Fy4aE1PHzSNr2FqT4rUSYrT4N8cL # QiPeB8JiJUnl73TcCkTwi7S/Az+37okv+Qsr7eh1wdarY8DOYir9dGJU3TGzICSw # cgPImb99rhBc2kEmwciCWGlhXIMD8WNN64EanPPg5VeQYdzrorYwl7jCTMQMBR5H # wtOq3f6FfYJonVwZ6YOmbioD2mFfoGBuiDcYmTTw440vrruKqHagbm5onD1SY9kR # SM0/HXcYaKB6Ae9qNKhyR9h94KZzDUkCvcTLdFGtK90GBs4VxZVHQn6Dpkh5lPtT # t0MbMv1mcO6ODzg9TxO3gUAgoklTy3gM2wISXo5C9NGuxmF2svwkuQl5pg== # =CuIa # -----END PGP SIGNATURE----- # gpg: Signature made Fri 22 Sep 2023 11:40:53 EDT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: vl: recognize audiodev groups in configuration files tests/qtest: Specify audiodev= and -audiodev hw/display/xlnx_dp.c: Add audiodev property hw/audio/lm4549: Add errp error reporting to init function hw/audio: Simplify hda audio init hw/input/tsc210x: Extract common init code into new function qemu/timer: Add host ticks function for RISC-V target/i386: Export GDS_NO bit to guests target/i386: enumerate bit 56 of MSR_IA32_VMX_BASIC Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-09-21target/i386: Export GDS_NO bit to guestsPawan Gupta
Gather Data Sampling (GDS) is a side-channel attack using Gather instructions. Some Intel processors will set ARCH_CAP_GDS_NO bit in MSR IA32_ARCH_CAPABILITIES to report that they are not vulnerable to GDS. Make this bit available to guests. Closes: https://lore.kernel.org/qemu-devel/CAMGffEmG6TNq0n3+4OJAgXc8J0OevY60KHZekXCBs3LoK9vehA@mail.gmail.com/ Reported-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Tested-by: Jack Wang <jinpu.wang@ionos.com> Tested-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> Message-ID: <fde42d81ce454477ca8e27d5429a190b7366fe86.1692074650.git.pawan.kumar.gupta@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-21target/i386: enumerate bit 56 of MSR_IA32_VMX_BASICPaolo Bonzini
On parts that enumerate IA32_VMX_BASIC MSR bit as 1, any exception vector can be delivered with or without an error code if the other consistency checks are satisfied. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-20i386: spelling fixesMichael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-09-13target/i386: Call accel-agnostic x86_cpu_get_supported_cpuid()Philippe Mathieu-Daudé
x86_cpu_get_supported_cpuid() is generic and handles the different accelerators. Use it instead of kvm_arch_get_supported_cpuid(). That fixes a link failure introduced by commit 3adce820cf ("target/i386: Remove unused KVM stubs") when QEMU is configured as: $ ./configure --cc=clang \ --target-list=x86_64-linux-user,x86_64-softmmu \ --enable-debug We were getting: [71/71] Linking target qemu-x86_64 FAILED: qemu-x86_64 /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `cpu_x86_cpuid': cpu.c:(.text+0x1374): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `x86_cpu_filter_features': cpu.c:(.text+0x81c2): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x81da): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x81f2): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: cpu.c:(.text+0x820a): undefined reference to `kvm_arch_get_supported_cpuid' /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o:cpu.c:(.text+0x8225): more undefined references to `kvm_arch_get_supported_cpuid' follow clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. For the record, this is because '--enable-debug' disables optimizations (CFLAGS=-O0). While at this (un)optimization level GCC eliminate the following dead code (CPP output of mentioned build): static void x86_cpu_get_supported_cpuid(uint32_t func, uint32_t index, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx) { if ((0)) { *eax = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EAX); *ebx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EBX); *ecx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_ECX); *edx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EDX); } else if (0) { *eax = 0; *ebx = 0; *ecx = 0; *edx = 0; } else { *eax = 0; *ebx = 0; *ecx = 0; *edx = 0; } Clang does not (see commit 2140cfa51d "i386: Fix build by providing stub kvm_arch_get_supported_cpuid()"). Cc: qemu-stable@nongnu.org Fixes: 3adce820cf ("target/i386: Remove unused KVM stubs") Reported-by: Kevin Wolf <kwolf@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-4-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-13target/i386: Drop accel_uses_host_cpuid before x86_cpu_get_supported_cpuidPhilippe Mathieu-Daudé
x86_cpu_get_supported_cpuid() already checks for KVM/HVF accelerators, so it is not needed to manually check it via a call to accel_uses_host_cpuid() before calling it. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-3-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-13target/i386: Check kvm_hyperv_expand_features() return valuePhilippe Mathieu-Daudé
In case more code is added after the kvm_hyperv_expand_features() call, check its return value (since it can fail). Fixes: 071ce4b03b ("i386: expand Hyper-V features during CPU feature expansion time") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230913093009.83520-2-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-01target/i386: Add support for AMX-COMPLEX in CPUID enumerationTao Su
Latest Intel platform GraniteRapids-D introduces AMX-COMPLEX, which adds two instructions to perform matrix multiplication of two tiles containing complex elements and accumulate the results into a packed single precision tile. AMX-COMPLEX is enumerated via CPUID.(EAX=7,ECX=1):EDX[bit 8]. Add the CPUID definition for AMX-COMPLEX, AMX-COMPLEX will be enabled automatically when using '-cpu host' and KVM advertises AMX-COMPLEX to userspace. Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20230830074324.84059-1-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-08-28target/i386: add support for VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSEAke Koomsin
Current QEMU can expose waitpkg to guests when it is available. However, VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE is still not recognized and masked by QEMU. This can lead to an unexpected situation when a L1 hypervisor wants to expose waitpkg to a L2 guest. The L1 hypervisor can assume that VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE exists as waitpkg is available. The L1 hypervisor then can accidentally expose waitpkg to the L2 guest. This will cause invalid opcode exception in the L2 guest when it executes waitpkg related instructions. This patch adds VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE support, and sets up dependency between the bit and CPUID_7_0_ECX_WAITPKG. QEMU should not expose waitpkg feature if VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE is not available to avoid unexpected invalid opcode exception in L2 guests. Signed-off-by: Ake Koomsin <ake@igel.co.jp> Message-ID: <20230807093339.32091-2-ake@igel.co.jp> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-07-07target/i386: Add new CPU model GraniteRapidsTao Su
The GraniteRapids CPU model mainly adds the following new features based on SapphireRapids: - PREFETCHITI CPUID.(EAX=7,ECX=1):EDX[bit 14] - AMX-FP16 CPUID.(EAX=7,ECX=1):EAX[bit 21] And adds the following security fix for corresponding vulnerabilities: - MCDT_NO CPUID.(EAX=7,ECX=2):EDX[bit 5] - SBDR_SSDP_NO MSR_IA32_ARCH_CAPABILITIES[bit 13] - FBSDP_NO MSR_IA32_ARCH_CAPABILITIES[bit 14] - PSDP_NO MSR_IA32_ARCH_CAPABILITIES[bit 15] - PBRSB_NO MSR_IA32_ARCH_CAPABILITIES[bit 24] Signed-off-by: Tao Su <tao1.su@linux.intel.com> Tested-by: Xuelian Guo <xuelian.guo@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20230706054949.66556-7-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-07-07target/i386: Add few security fix bits in ARCH_CAPABILITIES into ↵Lei Wang
SapphireRapids CPU model SapphireRapids has bit 13, 14 and 15 of MSR_IA32_ARCH_CAPABILITIES enabled, which are related to some security fixes. Add version 2 of SapphireRapids CPU model with those bits enabled also. Signed-off-by: Lei Wang <lei4.wang@intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Message-ID: <20230706054949.66556-6-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-07-07target/i386: Add support for MCDT_NO in CPUID enumerationTao Su
CPUID.(EAX=7,ECX=2):EDX[bit 5] enumerates MCDT_NO. Processors enumerate this bit as 1 do not exhibit MXCSR Configuration Dependent Timing (MCDT) behavior and do not need to be mitigated to avoid data-dependent behavior for certain instructions. Since MCDT_NO is in a new sub-leaf, add a new CPUID feature word FEAT_7_2_EDX. Also update cpuid_level_func7 by FEAT_7_2_EDX. Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20230706054949.66556-3-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-07-07target/i386: Adjust feature level according to FEAT_7_1_EDXTao Su
If FEAT_7_1_EAX is 0 and FEAT_7_1_EDX is non-zero, as is the case with a Granite Rapids host and '-cpu host,-avx-vnni,-avx512-bf16,-fzrm,-fsrs,-fsrc,-amx-fp16', we can't get CPUID_7_1 leaf even though CPUID_7_1_EDX has non-zero value. Update cpuid_level_func7 according to CPUID_7_1_EDX, otherwise guest may report wrong maximum number sub-leaves in leaf 07H. Fixes: eaaa197d5b11 ("target/i386: Add support for AVX-VNNI-INT8 in CPUID enumeration") Cc: qemu-stable@nongnu.org Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20230706054949.66556-2-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-29target/i386: emulate 64-bit ring 0 for linux-user if LM feature is setPaolo Bonzini
32-bit binaries can run on a long mode processor even if the kernel is 64-bit, of course, and this can have slightly different behavior; for example, SYSCALL is allowed on Intel processors. Allow reporting LM to programs running under user mode emulation, so that "-cpu" can be used with named CPU models even for qemu-i386 and even without disabling LM by hand. Fortunately, most of the runtime code in QEMU has to depend on HF_LMA_MASK or on HF_CS64_MASK (which is anyway false for qemu-i386's 32-bit code segment) rather than TARGET_X86_64, therefore all that is needed is an update of linux-user's ring 0 setup. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1534 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-29target/i386: ignore CPL0-specific features in user mode emulationPaolo Bonzini
Features such as PCID are only accessible through privileged operations, and therefore have no impact on any user-mode operation. Allow reporting them to programs running under user mode emulation, so that "-cpu" can be used with more named CPU models. XSAVES would be similar, but it doesn't make sense to provide it until XSAVEC is implemented. With this change, all CPUs up to Broadwell-v4 can be emulate. Skylake-Client requires XSAVEC, while EPYC also requires SHA-NI, MISALIGNSSE and TOPOEXT. MISALIGNSSE is not hard to implement, but I am not sure it is worth using a precious hflags bit for it. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1534 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-29target/i386: ignore ARCH_CAPABILITIES features in user mode emulationPaolo Bonzini
ARCH_CAPABILITIES is only accessible through a read-only MSR, so it has no impact on any user-mode operation (user-mode cannot read the MSR). So do not bother printing warnings about it in user mode emulation. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-29target/i386: Export MSR_ARCH_CAPABILITIES bits to guestsPawan Gupta
On Intel CPUs there are certain bits in MSR_ARCH_CAPABILITIES that indicates if the CPU is not affected by a vulnerability. Without these bits guests may try to deploy the mitigation even if the CPU is not affected. Export the bits to guests that indicate immunity to hardware vulnerabilities. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Message-ID: <63d85cc76d4cdc51e6c732478b81d8f13be11e5a.1687551881.git.pawan.kumar.gupta@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: implement SYSCALL/SYSRET in 32-bit emulatorsPaolo Bonzini
AMD supports both 32-bit and 64-bit SYSCALL/SYSRET, but the TCG only exposes it for 64-bit targets. For system emulation just reuse the helper; for user-mode emulation the ABI is the same as "int $80". The BSDs does not support any fast system call mechanism in 32-bit mode so add to bsd-user the same stub that FreeBSD has for 64-bit compatibility mode. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: implement RDPID in TCGPaolo Bonzini
RDPID corresponds to a RDMSR(TSC_AUX); however, it is unprivileged so for user-mode emulation we must provide the value that the kernel places in the MSR. For Linux, it is a combination of the current CPU and the current NUMA node, both of which can be retrieved with getcpu(2). Also try sched_getcpu(), which might be there on the BSDs. If there is no portable way to retrieve the current CPU id from userspace, return 0. RDTSCP is reimplemented as RDTSC + RDPID ECX; the differences in terms of serializability are not relevant to QEMU. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: Intel only supports SYSCALL/SYSRET in long modePaolo Bonzini
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: TCG supports WBNOINVDPaolo Bonzini
WBNOINVD is the same as INVD or WBINVD as far as TCG is concerned, since there is no cache in TCG and therefore no invalidation side effect in WBNOINVD. With respect to SVM emulation, processors that do not support WBNOINVD will ignore the prefix and treat it as WBINVD, while those that support it will generate exactly the same vmexit. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: TCG supports XSAVEERPTRPaolo Bonzini
XSAVEERPTR is actually a fix for an errata; TCG does not have the issue. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: TCG supports RDSEEDPaolo Bonzini
TCG implements RDSEED, and in fact uses qcrypto_random_bytes which is secure enough to match hardware behavior. Expose it to guests. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-06-26target/i386: TCG supports 3DNow! prefetch(w)Paolo Bonzini
The AMD prefetch(w) instructions have not been deprecated together with the rest of 3DNow!, and in fact are even supported by newer Intel processor. Mark them as supported by TCG, as it supports all of 3DNow!. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-25target/i386: EPYC-Rome model without XSAVESMaksim Davydov
Based on the kernel commit "b0563468ee x86/CPU/AMD: Disable XSAVES on AMD family 0x17", host system with EPYC-Rome can clear XSAVES capability bit. In another words, EPYC-Rome host without XSAVES can occur. Thus, we need an EPYC-Rome cpu model (without this feature) that matches the solution of fixing this erratum Signed-off-by: Maksim Davydov <davydov-max@yandex-team.ru> Message-Id: <20230524213748.8918-1-davydov-max@yandex-team.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18target/i386: add support for FB_CLEAR featureEmanuele Giuseppe Esposito
As reported by the Intel's doc: "FB_CLEAR: The processor will overwrite fill buffer values as part of MD_CLEAR operations with the VERW instruction. On these processors, L1D_FLUSH does not overwrite fill buffer values." If this cpu feature is present in host, allow QEMU to choose whether to show it to the guest too. One disadvantage of not exposing it is that the guest will report a non existing vulnerability in /sys/devices/system/cpu/vulnerabilities/mmio_stale_data because the mitigation is present only when the cpu has (FLUSH_L1D and MD_CLEAR) or FB_CLEAR features enabled. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20230201135759.555607-3-eesposit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18target/i386: add support for FLUSH_L1D featureEmanuele Giuseppe Esposito
As reported by Intel's doc: "L1D_FLUSH: Writeback and invalidate the L1 data cache" If this cpu feature is present in host, allow QEMU to choose whether to show it to the guest too. One disadvantage of not exposing it is that the guest will report a non existing vulnerability in /sys/devices/system/cpu/vulnerabilities/mmio_stale_data because the mitigation is present only when the cpu has (FLUSH_L1D and MD_CLEAR) or FB_CLEAR features enabled. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20230201135759.555607-2-eesposit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add EPYC-Genoa model to support Zen 4 processor seriesBabu Moger
Adds the support for AMD EPYC Genoa generation processors. The model display for the new processor will be EPYC-Genoa. Adds the following new feature bits on top of the feature bits from the previous generation EPYC models. avx512f : AVX-512 Foundation instruction avx512dq : AVX-512 Doubleword & Quadword Instruction avx512ifma : AVX-512 Integer Fused Multiply Add instruction avx512cd : AVX-512 Conflict Detection instruction avx512bw : AVX-512 Byte and Word Instructions avx512vl : AVX-512 Vector Length Extension Instructions avx512vbmi : AVX-512 Vector Byte Manipulation Instruction avx512_vbmi2 : AVX-512 Additional Vector Byte Manipulation Instruction gfni : AVX-512 Galois Field New Instructions avx512_vnni : AVX-512 Vector Neural Network Instructions avx512_bitalg : AVX-512 Bit Algorithms, add bit algorithms Instructions avx512_vpopcntdq: AVX-512 AVX-512 Vector Population Count Doubleword and Quadword Instructions avx512_bf16 : AVX-512 BFLOAT16 instructions la57 : 57-bit virtual address support (5-level Page Tables) vnmi : Virtual NMI (VNMI) allows the hypervisor to inject the NMI into the guest without using Event Injection mechanism meaning not required to track the guest NMI and intercepting the IRET. auto-ibrs : The AMD Zen4 core supports a new feature called Automatic IBRS. It is a "set-and-forget" feature that means that, unlike e.g., s/w-toggled SPEC_CTRL.IBRS, h/w manages its IBRS mitigation resources automatically across CPL transitions. Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <20230504205313.225073-8-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add VNMI and automatic IBRS feature bitsBabu Moger
Add the following featute bits. vnmi: Virtual NMI (VNMI) allows the hypervisor to inject the NMI into the guest without using Event Injection mechanism meaning not required to track the guest NMI and intercepting the IRET. The presence of this feature is indicated via the CPUID function 0x8000000A_EDX[25]. automatic-ibrs : The AMD Zen4 core supports a new feature called Automatic IBRS. It is a "set-and-forget" feature that means that, unlike e.g., s/w-toggled SPEC_CTRL.IBRS, h/w manages its IBRS mitigation resources automatically across CPL transitions. The presence of this feature is indicated via the CPUID function 0x80000021_EAX[8]. The documention for the features are available in the links below. a. Processor Programming Reference (PPR) for AMD Family 19h Model 01h, Revision B1 Processors b. AMD64 Architecture Programmer’s Manual Volumes 1–5 Publication No. Revision 40332 4.05 Date October 2022 Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Link: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip Link: https://www.amd.com/system/files/TechDocs/40332_4.05.pdf Message-Id: <20230504205313.225073-7-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add missing feature bits in EPYC-Milan modelBabu Moger
Add the following feature bits for EPYC-Milan model and bump the version. vaes : Vector VAES(ENC|DEC), VAES(ENC|DEC)LAST instruction support vpclmulqdq : Vector VPCLMULQDQ instruction support stibp-always-on : Single Thread Indirect Branch Prediction Mode has enhanced performance and may be left Always on amd-psfd : Predictive Store Forward Disable no-nested-data-bp : Processor ignores nested data breakpoints lfence-always-serializing : LFENCE instruction is always serializing null-sel-clr-base : Null Selector Clears Base. When this bit is set, a null segment load clears the segment base These new features will be added in EPYC-Milan-v2. The "-cpu help" output after the change will be. x86 EPYC-Milan (alias configured by machine type) x86 EPYC-Milan-v1 AMD EPYC-Milan Processor x86 EPYC-Milan-v2 AMD EPYC-Milan Processor The documentation for the features are available in the links below. a. Processor Programming Reference (PPR) for AMD Family 19h Model 01h, Revision B1 Processors b. SECURITY ANALYSIS OF AMD PREDICTIVE STORE FORWARDING c. AMD64 Architecture Programmer’s Manual Volumes 1–5 Publication No. Revision 40332 4.05 Date October 2022 Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip Link: https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf Link: https://www.amd.com/system/files/TechDocs/40332_4.05.pdf Message-Id: <20230504205313.225073-6-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add feature bits for CPUID_Fn80000021_EAXBabu Moger
Add the following feature bits. no-nested-data-bp : Processor ignores nested data breakpoints. lfence-always-serializing : LFENCE instruction is always serializing. null-sel-cls-base : Null Selector Clears Base. When this bit is set, a null segment load clears the segment base. The documentation for the features are available in the links below. a. Processor Programming Reference (PPR) for AMD Family 19h Model 01h, Revision B1 Processors b. AMD64 Architecture Programmer’s Manual Volumes 1–5 Publication No. Revision 40332 4.05 Date October 2022 Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip Link: https://www.amd.com/system/files/TechDocs/40332_4.05.pdf Message-Id: <20230504205313.225073-5-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add a couple of feature bits in 8000_0008_EBXBabu Moger
Add the following feature bits. amd-psfd : Predictive Store Forwarding Disable: PSF is a hardware-based micro-architectural optimization designed to improve the performance of code execution by predicting address dependencies between loads and stores. While SSBD (Speculative Store Bypass Disable) disables both PSF and speculative store bypass, PSFD only disables PSF. PSFD may be desirable for the software which is concerned with the speculative behavior of PSF but desires a smaller performance impact than setting SSBD. Depends on the following kernel commit: b73a54321ad8 ("KVM: x86: Expose Predictive Store Forwarding Disable") stibp-always-on : Single Thread Indirect Branch Prediction mode has enhanced performance and may be left always on. The documentation for the features are available in the links below. a. Processor Programming Reference (PPR) for AMD Family 19h Model 01h, Revision B1 Processors b. SECURITY ANALYSIS OF AMD PREDICTIVE STORE FORWARDING Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf Link: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip Message-Id: <20230504205313.225073-4-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: Add new EPYC CPU versions with updated cache_infoMichael Roth
Introduce new EPYC cpu versions: EPYC-v4 and EPYC-Rome-v3. The only difference vs. older models is an updated cache_info with the 'complex_indexing' bit unset, since this bit is not currently defined for AMD and may cause problems should it be used for something else in the future. Setting this bit will also cause CPUID validation failures when running SEV-SNP guests. Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20230504205313.225073-3-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-08target/i386: allow versioned CPUs to specify new cache_infoMichael Roth
New EPYC CPUs versions require small changes to their cache_info's. Because current QEMU x86 CPU definition does not support versioned cach_info, we would have to declare a new CPU type for each such case. To avoid the dup work, add "cache_info" in X86CPUVersionDefinition", to allow new cache_info pointers to be specified for a new CPU version. Co-developed-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20230504205313.225073-2-babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28target/i386: Add support for PREFETCHIT0/1 in CPUID enumerationJiaxi Chen
Latest Intel platform Granite Rapids has introduced a new instruction - PREFETCHIT0/1, which moves code to memory (cache) closer to the processor depending on specific hints. The bit definition: CPUID.(EAX=7,ECX=1):EDX[bit 14] Add CPUID definition for PREFETCHIT0/1. Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20230303065913.1246327-7-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28target/i386: Add support for AVX-NE-CONVERT in CPUID enumerationJiaxi Chen
AVX-NE-CONVERT is a new set of instructions which can convert low precision floating point like BF16/FP16 to high precision floating point FP32, as well as convert FP32 elements to BF16. This instruction allows the platform to have improved AI capabilities and better compatibility. The bit definition: CPUID.(EAX=7,ECX=1):EDX[bit 5] Add CPUID definition for AVX-NE-CONVERT. Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20230303065913.1246327-6-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28target/i386: Add support for AVX-VNNI-INT8 in CPUID enumerationJiaxi Chen
AVX-VNNI-INT8 is a new set of instructions in the latest Intel platform Sierra Forest, aims for the platform to have superior AI capabilities. This instruction multiplies the individual bytes of two unsigned or unsigned source operands, then adds and accumulates the results into the destination dword element size operand. The bit definition: CPUID.(EAX=7,ECX=1):EDX[bit 4] AVX-VNNI-INT8 is on a new feature bits leaf. Add a CPUID feature word FEAT_7_1_EDX for this leaf. Add CPUID definition for AVX-VNNI-INT8. Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20230303065913.1246327-5-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28target/i386: Add support for AVX-IFMA in CPUID enumerationJiaxi Chen
AVX-IFMA is a new instruction in the latest Intel platform Sierra Forest. This instruction packed multiplies unsigned 52-bit integers and adds the low/high 52-bit products to Qword Accumulators. The bit definition: CPUID.(EAX=7,ECX=1):EAX[bit 23] Add CPUID definition for AVX-IFMA. Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20230303065913.1246327-4-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28target/i386: Add support for AMX-FP16 in CPUID enumerationJiaxi Chen
Latest Intel platform Granite Rapids has introduced a new instruction - AMX-FP16, which performs dot-products of two FP16 tiles and accumulates the results into a packed single precision tile. AMX-FP16 adds FP16 capability and allows a FP16 GPU trained model to run faster without loss of accuracy or added SW overhead. The bit definition: CPUID.(EAX=7,ECX=1):EAX[bit 21] Add CPUID definition for AMX-FP16. Signed-off-by: Jiaxi Chen <jiaxi.chen@linux.intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20230303065913.1246327-3-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 20:54:04 +0000