summary refs log tree commit diff stats
path: root/target/i386/cpu.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* target/i386/cpu: Remove "x86" prefix from the CPU listThomas Huth2024-04-291-1/+1
| | | | | | | | | | | | | | | | Printing an "x86" in front of each CPU name is not helpful at all: It is confusing for the users since they don't know whether they have to specify these letters for the "-cpu" parameter, too, and it also takes some precious space in the dense output of the CPU entries. Let's simply remove this now and use two spaces at the beginning of the lines for the indentation of the entries instead, like most other target architectures are doing it for their CPU help output already. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* hw, target: Add ResetType argument to hold and exit phase methodsPeter Maydell2024-04-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | We pass a ResetType argument to the Resettable class enter phase method, but we don't pass it to hold and exit, even though the callsites have it readily available. This means that if a device cared about the ResetType it would need to record it in the enter phase method to use later on. Pass the type to all three of the phase methods to avoid having to do that. Commit created with for dir in hw target include; do \ spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/reset-type.cocci \ --keep-comments --smpl-spacing --in-place \ --include-headers --dir $dir; done and no manual edits. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@amd.com> Message-id: 20240412160809.1260625-5-peter.maydell@linaro.org
* target/i386/cpu: Merge the warning and error messages for AMD HT checkZhao Liu2024-04-231-3/+3
| | | | | | | | | | | | | | | | | | Currently, the difference between warn_report_once() and error_report_once() is the former has the "warning:" prefix, while the latter does not have a similar level prefix. At the meantime, considering that there is no error handling logic here, and the purpose of error_report_once() is only to prompt the user with an abnormal message, there is no need to use an error-level message here, and instead we can just use a warning. Therefore, downgrade the message in error_report_once() to warning, and merge it into the previous warn_report_once(). Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240327103951.3853425-4-zhao1.liu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386/cpu: Consolidate the use of warn_report_once()Zhao Liu2024-04-231-8/+5
| | | | | | | | | | | | | | The difference between error_printf() and error_report() is the latter may contain more information, such as the name of the program ("qemu-system-x86_64"). Thus its variant error_report_once() and warn_report()'s variant warn_report_once() can be used here to print the information only once without a static local variable "ht_warned". Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240327103951.3853425-3-zhao1.liu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Export RFDS bit to guestsPawan Gupta2024-04-231-2/+2
| | | | | | | | | | | | | | | | Register File Data Sampling (RFDS) is a CPU side-channel vulnerability that may expose stale register value. CPUs that set RFDS_NO bit in MSR IA32_ARCH_CAPABILITIES indicate that they are not vulnerable to RFDS. Similarly, RFDS_CLEAR indicates that CPU is affected by RFDS, and has the microcode to help mitigate RFDS. Make RFDS_CLEAR and RFDS_NO bits available to guests. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <9a38877857392b5c2deae7e7db1b170d15510314.1710341348.git.pawan.kumar.gupta@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Add new CPU model SierraForestTao Su2024-04-231-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to table 1-2 in Intel Architecture Instruction Set Extensions and Future Features (rev 051) [1], SierraForest has the following new features which have already been virtualized: - CMPCCXADD CPUID.(EAX=7,ECX=1):EAX[bit 7] - AVX-IFMA CPUID.(EAX=7,ECX=1):EAX[bit 23] - AVX-VNNI-INT8 CPUID.(EAX=7,ECX=1):EDX[bit 4] - AVX-NE-CONVERT CPUID.(EAX=7,ECX=1):EDX[bit 5] Add above features to new CPU model SierraForest. Comparing with GraniteRapids CPU model, SierraForest bare-metal removes the following features: - HLE CPUID.(EAX=7,ECX=0):EBX[bit 4] - RTM CPUID.(EAX=7,ECX=0):EBX[bit 11] - AVX512F CPUID.(EAX=7,ECX=0):EBX[bit 16] - AVX512DQ CPUID.(EAX=7,ECX=0):EBX[bit 17] - AVX512_IFMA CPUID.(EAX=7,ECX=0):EBX[bit 21] - AVX512CD CPUID.(EAX=7,ECX=0):EBX[bit 28] - AVX512BW CPUID.(EAX=7,ECX=0):EBX[bit 30] - AVX512VL CPUID.(EAX=7,ECX=0):EBX[bit 31] - AVX512_VBMI CPUID.(EAX=7,ECX=0):ECX[bit 1] - AVX512_VBMI2 CPUID.(EAX=7,ECX=0):ECX[bit 6] - AVX512_VNNI CPUID.(EAX=7,ECX=0):ECX[bit 11] - AVX512_BITALG CPUID.(EAX=7,ECX=0):ECX[bit 12] - AVX512_VPOPCNTDQ CPUID.(EAX=7,ECX=0):ECX[bit 14] - LA57 CPUID.(EAX=7,ECX=0):ECX[bit 16] - TSXLDTRK CPUID.(EAX=7,ECX=0):EDX[bit 16] - AMX-BF16 CPUID.(EAX=7,ECX=0):EDX[bit 22] - AVX512_FP16 CPUID.(EAX=7,ECX=0):EDX[bit 23] - AMX-TILE CPUID.(EAX=7,ECX=0):EDX[bit 24] - AMX-INT8 CPUID.(EAX=7,ECX=0):EDX[bit 25] - AVX512_BF16 CPUID.(EAX=7,ECX=1):EAX[bit 5] - fast zero-length MOVSB CPUID.(EAX=7,ECX=1):EAX[bit 10] - fast short CMPSB, SCASB CPUID.(EAX=7,ECX=1):EAX[bit 12] - AMX-FP16 CPUID.(EAX=7,ECX=1):EAX[bit 21] - PREFETCHI CPUID.(EAX=7,ECX=1):EDX[bit 14] - XFD CPUID.(EAX=0xD,ECX=1):EAX[bit 4] - EPT_PAGE_WALK_LENGTH_5 VMX_EPT_VPID_CAP(0x48c)[bit 7] Add all features of GraniteRapids CPU model except above features to SierraForest CPU model. SierraForest doesn’t support TSX and RTM but supports TAA_NO. When RTM is not enabled in host, KVM will not report TAA_NO. So, just don't include TAA_NO in SierraForest CPU model. [1] https://cdrdv2.intel.com/v1/dl/getContent/671368 Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Message-ID: <20240320021044.508263-1-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Introduce Icelake-Server-v7 to enable TSXZhenzhong Duan2024-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | When start L2 guest with both L1/L2 using Icelake-Server-v3 or above, QEMU reports below warning: "warning: host doesn't support requested feature: MSR(10AH).taa-no [bit 8]" Reason is QEMU Icelake-Server-v3 has TSX feature disabled but enables taa-no bit. It's meaningless that TSX isn't supported but still claim TSX is secure. So L1 KVM doesn't expose taa-no to L2 if TSX is unsupported, then starting L2 triggers the warning. Fix it by introducing a new version Icelake-Server-v7 which has both TSX and taa-no features. Then guest can use TSX securely when it see taa-no. This matches the production Icelake which supports TSX and isn't susceptible to TSX Async Abort (TAA) vulnerabilities, a.k.a, taa-no. Ideally, TSX should have being enabled together with taa-no since v3, but for compatibility, we'd better to add v7 to enable it. Fixes: d965dc35592d ("target/i386: Add ARCH_CAPABILITIES related bits into Icelake-Server CPU model") Tested-by: Xiangfei Ma <xiangfeix.ma@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-ID: <20240320093138.80267-2-zhenzhong.duan@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: add guest-phys-bits cpu propertyGerd Hoffmann2024-04-181-0/+22
| | | | | | | | | | Allows to set guest-phys-bits (cpuid leaf 80000008, eax[23:16]) via -cpu $model,guest-phys-bits=$nr. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-ID: <20240318155336.156197-3-kraxel@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: fix direction of "32-bit MMU" testPaolo Bonzini2024-03-181-1/+1
| | | | | | | | | | | | | The low bit of MMU indices for x86 TCG indicates whether the processor is in 32-bit mode and therefore linear addresses have to be masked to 32 bits. However, the index was computed incorrectly, leading to possible conflicts in the TLB for any address above 4G. Analyzed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: b1661801c18 ("target/i386: Fix physical address truncation", 2024-02-28) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2206 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handlerPhilippe Mathieu-Daudé2024-03-121-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | Since CPU() macro is a simple cast, the following are equivalent: Object *obj; CPUState *cs = CPU(obj) In order to ease static analysis when running scripts/coccinelle/cpu_env.cocci from the previous commit, replace: - CPU_GET_CLASS(cpu); + CPU_GET_CLASS(obj); Most code use the 'cs' variable name for CPUState handle. Replace few 's' -> 'cs' to unify cpu_reset_hold() style. No logical change in this patch. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240129164514.73104-7-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
* Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingPeter Maydell2024-02-281-3/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * target/i386: Fix physical address truncation on 32-bit PAE * Remove globals for options -no-fd-bootchk and -win2k-hack # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmXebwQUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroPozAf/Vgc9u6C+8PcPDrol6qxjI+EOHLNy # 7M3/OFpUkwLXuOSawb6syYxHpLS38fKRcsb2ninngUmbRWA6p+KNUizlAFMj7op5 # wJmtdamCwCwXXaw20SfWxx2Ih0JS7FQsRsU94HTOdaDB17C9+hBcYwcggsOAXCmq # gyVenEF1mov2A4jLMhdVIRX784AAoEP+QAuhBKQBrQwRLCTTyNdHl7jXdB9w+2sh # KafokoFLcozJHz/tN3AhRKy6zjPugJyQmJwBRuj9tstCILtXpvf/ZE/3pUq5l3ZY # A6dCI0zWAlGNTkpKRXsMFozNIVP2htnyidy29XHptlY5acfjtQ++rMu3BQ== # =WY4H # -----END PGP SIGNATURE----- # gpg: Signature made Tue 27 Feb 2024 23:23:48 GMT # 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: ide, vl: turn -win2k-hack into a property on IDE devices ide: collapse parameters to ide_init_drive target/i386: leave the A20 bit set in the final NPT walk target/i386: remove unnecessary/wrong application of the A20 mask target/i386: Fix physical address truncation target/i386: use separate MMU indexes for 32-bit accesses target/i386: introduce function to query MMU indices target/i386: check validity of VMCB addresses target/i386: mask high bits of CR3 in 32-bit mode vl, pc: turn -no-fd-bootchk into a machine property Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * target/i386: Fix physical address truncationPaolo Bonzini2024-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorrect when using physical address extensions (PAE) outside of long mode, with the result that a 32-bit operating system using PAE to access memory above 4G will experience undefined behaviour. The truncation code was originally introduced in commit 33dfdb5 ("x86: only allow real mode to access 32bit without LMA"), where it applied only to translations performed while paging is disabled (and so cannot affect guests using PAE). Commit 9828198 ("target/i386: Add MMU_PHYS_IDX and MMU_NESTED_IDX") rearranged the code such that the truncation also applied to the use of MMU_PHYS_IDX and MMU_NESTED_IDX. Commit 4a1e9d4 ("target/i386: Use atomic operations for pte updates") brought this truncation into scope for page table entry accesses, and is the first commit for which a Windows 10 32-bit guest will reliably fail to boot if memory above 4G is present. The truncation code however is not completely redundant. Even though the maximum address size for any executed instruction is 32 bits, helpers for operations such as BOUND, FSAVE or XSAVE may ask get_physical_address() to translate an address outside of the 32-bit range, if invoked with an argument that is close to the 4G boundary. Likewise for processor accesses, for example TSS or IDT accesses, when EFER.LMA==0. So, move the address truncation in get_physical_address() so that it applies to 32-bit MMU indexes, but not to MMU_PHYS_IDX and MMU_NESTED_IDX. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2040 Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Cc: qemu-stable@nongnu.org Co-developed-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * target/i386: use separate MMU indexes for 32-bit accessesPaolo Bonzini2024-02-281-4/+7
| | | | | | | | | | | | | | | | | | | | | | Accesses from a 32-bit environment (32-bit code segment for instruction accesses, EFER.LMA==0 for processor accesses) have to mask away the upper 32 bits of the address. While a bit wasteful, the easiest way to do so is to use separate MMU indexes. These days, QEMU anyway is compiled with a fixed value for NB_MMU_MODES. Split MMU_USER_IDX, MMU_KSMAP_IDX and MMU_KNOSMAP_IDX in two. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | gdbstub: Infer number of core registers from XMLAkihiko Odaki2024-02-281-2/+0
|/ | | | | | | | | | | GDBFeature has the num_regs member so use it where applicable to remove magic numbers. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231213-gdb-v17-8-777047380591@daynix.com> [AJB: remove core reg check from microblaze read reg] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-13-alex.bennee@linaro.org>
* target/i386: do not filter processor tracing features except on KVMPaolo Bonzini2024-02-231-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The processor tracing features in cpu_x86_cpuid() are hardcoded to a set that should be safe on all processor that support PT virtualization. But as an additional check, x86_cpu_filter_features() also checks that the accelerator supports that safe subset, and if not it marks CPUID_7_0_EBX_INTEL_PT as unavailable. This check fails on accelerators other than KVM, but it is actually unnecessary to do it because KVM is the only accelerator that uses the safe subset. Everything else just provides nonzero values for CPUID leaf 0x14 (TCG/HVF because processor tracing is not supported; qtest because nothing is able to read CPUID anyway). Restricting the check to KVM fixes a warning with the qtest accelerator: $ qemu-system-x86_64 -display none -cpu max,mmx=off -accel qtest qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] The warning also happens in the test-x86-cpuid-compat qtest. Reported-by: Peter Maydell <peter.maydell@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2096 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240221162910.101327-1-pbonzini@redhat.com> Fixes: d047402436 ("target/i386: Call accel-agnostic x86_cpu_get_supported_cpuid()") Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
* target/i386: Add support of KVM_FEATURE_ASYNC_PF_VMEXIT for guestXiaoyao Li2024-02-161-1/+1
| | | | | | | | | KVM_FEATURE_ASYNC_PF_VMEXIT has been introduced for years, however QEMU doesn't support expose it to guest. Add support for it. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20231024083354.1171308-1-xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/cpu: Mask with XCR0/XSS mask for FEAT_XSAVE_XCR0_HI and ↵Xiaoyao Li2024-02-161-2/+2
| | | | | | | | | | | | | | | FEAT_XSAVE_XSS_HI leafs The value of FEAT_XSAVE_XCR0_HI leaf and FEAT_XSAVE_XSS_HI leaf also need to be masked by XCR0 and XSS mask respectively, to make it logically correct. Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Yang Weijiang <weijiang.yang@intel.com> Message-ID: <20240115091325.1904229-3-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/cpu: Clear FEAT_XSAVE_XSS_LO/HI leafs when CPUID_EXT_XSAVE is not availableXiaoyao Li2024-02-161-0/+2
| | | | | | | | | | | | Leaf FEAT_XSAVE_XSS_LO and FEAT_XSAVE_XSS_HI also need to be cleared when CPUID_EXT_XSAVE is not set. Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Yang Weijiang <weijiang.yang@intel.com> Message-ID: <20240115091325.1904229-2-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386/cpu: Fix typo in commentBernhard Beschow2024-02-141-1/+1
| | | | | | | | Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240106132546.21248-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* apic, i386/tcg: add x2apic transitionsBui Quang Minh2024-02-141-4/+5
| | | | | | | | | | | | | | | This commit adds support for x2APIC transitions when writing to MSR_IA32_APICBASE register and finally adds CPUID_EXT_X2APIC to TCG_EXT_FEATURES. The set_base in APICCommonClass now returns an integer to indicate error in execution. apic_set_base return -1 on invalid APIC state transition, accelerator can use this to raise appropriate exception. Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Message-Id: <20240111154404.5333-4-minhquangbui99@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* include/exec: Implement cpu_mmu_index genericallyRichard Henderson2024-02-031-1/+1
| | | | | | | | For user-only mode, use MMU_USER_IDX. For system mode, use CPUClass.mmu_index. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* target/i386: Populate CPUClass.mmu_indexRichard Henderson2024-02-031-0/+10
| | | | | Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* accel: Do not set CPUState::tcg_cflags in non-TCG accelsPhilippe Mathieu-Daudé2024-01-191-1/+1
| | | | | | | | 'tcg_cflags' is specific to TCG. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231130075958.21285-1-philmd@linaro.org>
* target: Use generic cpu_model_from_type()Gavin Shan2024-01-051-2/+1
| | | | | | | | | | | Use generic cpu_model_from_type() when the CPU model name needs to be extracted from the CPU type name. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231114235628.534334-23-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
* target/i386: implement CMPccXADDPaolo Bonzini2023-12-291-1/+1
| | | | | | | | | | | | The main difficulty here is that a page fault when writing to the destination must not overwrite the flags. Therefore, the flags computation must be inlined instead of using gen_jcc1*. For simplicity, I am using an unconditional cmpxchg operation, that becomes a NOP if the comparison fails. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target: Restrict 'sysemu/reset.h' to system emulationPhilippe Mathieu-Daudé2023-12-201-1/+1
| | | | | | | | | | | | vCPU "reset" is only possible with system emulation. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-ID: <20231212113640.30287-5-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
* target/i386/cpu: Improve error message for property "vendor"Markus Armbruster2023-11-171-1/+2
| | | | | | | | | | | | | | | | 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]
* system/cpus: Fix CPUState.nr_cores' calculationZhuocheng Ding2023-11-071-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* target/i386: check CPUID_PAE to determine 36 bit processor address spaceAni Sinha2023-10-251-1/+1
| | | | | | | | | | | | | 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>
* target/i386: implement SHA instructionsPaolo Bonzini2023-10-251-1/+1
| | | | | | | | | | | | | 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>
* target/i386/cpu: Fix CPUID_HT exposureXiaoyao Li2023-10-171-0/+1
| | | | | | | | | | | | | | | | 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>
* hw/core/cpu: Return static value with gdb_arch_name()Akihiko Odaki2023-10-111-3/+3
| | | | | | | | | | | | | | | | 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>
* target/i386: Check for USER_ONLY definition instead of SOFTMMU onePhilippe Mathieu-Daudé2023-10-071-1/+1
| | | | | | | | | | | | | 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>
* sysemu/kvm: Restrict hvf_get_supported_cpuid() to x86 targetsPhilippe Mathieu-Daudé2023-10-071-0/+1
| | | | | | | | | | | | | | | 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>
* accel/tcg: Remove cpu_set_cpustate_pointersRichard Henderson2023-10-041-1/+0
| | | | | | | | | 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>
* target/*: Add instance_align to all cpu base classesRichard Henderson2023-10-031-0/+1
| | | | | | | | 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>
* target/i386/cpu: avoid shadowed local variablesPaolo Bonzini2023-09-261-1/+2
| | | | | | Reuse the pointer variable used for the unversioned model. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingStefan Hajnoczi2023-09-251-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
| * target/i386: Export GDS_NO bit to guestsPawan Gupta2023-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * target/i386: enumerate bit 56 of MSR_IA32_VMX_BASICPaolo Bonzini2023-09-211-0/+1
| | | | | | | | | | | | | | | | 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>
* | i386: spelling fixesMichael Tokarev2023-09-201-2/+2
|/ | | | | Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
* target/i386: Call accel-agnostic x86_cpu_get_supported_cpuid()Philippe Mathieu-Daudé2023-09-131-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* target/i386: Drop accel_uses_host_cpuid before x86_cpu_get_supported_cpuidPhilippe Mathieu-Daudé2023-09-131-6/+4
| | | | | | | | | | | 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>
* target/i386: Check kvm_hyperv_expand_features() return valuePhilippe Mathieu-Daudé2023-09-131-2/+2
| | | | | | | | | | 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>
* target/i386: Add support for AMX-COMPLEX in CPUID enumerationTao Su2023-09-011-1/+1
| | | | | | | | | | | | | | | | 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>
* target/i386: add support for VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSEAke Koomsin2023-08-281-1/+5
| | | | | | | | | | | | | | | | | | | | 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>
* target/i386: Add new CPU model GraniteRapidsTao Su2023-07-071-0/+136
| | | | | | | | | | | | | | | | | | | | 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>
* target/i386: Add few security fix bits in ARCH_CAPABILITIES into ↵Lei Wang2023-07-071-2/+11
| | | | | | | | | | | | | | 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>
* target/i386: Add support for MCDT_NO in CPUID enumerationTao Su2023-07-071-0/+26
| | | | | | | | | | | | | | | 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>
* target/i386: Adjust feature level according to FEAT_7_1_EDXTao Su2023-07-071-0/+1
| | | | | | | | | | | | | | | | | 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>