summary refs log tree commit diff stats
path: root/target/i386/kvm/kvm-cpu.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* target/i386: Define enum X86ASIdx for x86's address spacesXiaoyao Li2025-09-171-1/+1
| | | | | | | | | | | | Define X86ASIdx as enum, like ARM's ARMASIdx, so that it's clear index 0 is for memory and index 1 is for SMM. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-By: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/cpu: Enable SMM cpu address space under KVMXiaoyao Li2025-09-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | Kirill Martynov reported assertation in cpu_asidx_from_attrs() being hit when x86_cpu_dump_state() is called to dump the CPU state[*]. It happens when the CPU is in SMM and KVM emulation failure due to misbehaving guest. The root cause is that QEMU i386 never enables the SMM address space for cpu since KVM SMM support has been added. Enable the SMM cpu address space under KVM when the SMM is enabled for the x86machine. [*] https://lore.kernel.org/qemu-devel/20250523154431.506993-1-stdcalllevi@yandex-team.ru/ Reported-by: Kirill Martynov <stdcalllevi@yandex-team.ru> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/kvm-cpu: Fix the indentation inside kvm_cpu_realizefn()Xiaoyao Li2025-07-121-1/+1
| | | | | | | | | The indentation of one of the } inside kvm_cpu_realizefn() isn'f correct. fix it. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250630080610.3151956-4-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: merge host_cpu_instance_init() and host_cpu_max_instance_init()Paolo Bonzini2025-07-121-2/+0
| | | | | | | | | Simplify the accelerators' cpu_instance_init callbacks by doing all host-cpu setup in a single function. Based-on: <20250711000603.438312-1-pbonzini@redhat.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: allow reordering max_x86_cpu_initfn vs accel CPU initPaolo Bonzini2025-07-121-0/+2
| | | | | | | | | | | | The PMU feature is only supported by KVM, so move it there. And since all accelerators other than TCG overwrite the vendor, set it in max_x86_cpu_initfn only if it has not been initialized by the superclass. This makes it possible to run max_x86_cpu_initfn after accelerator init. Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: move max_features to classPaolo Bonzini2025-07-111-2/+3
| | | | | | | | | | max_features is always set to true for instances created by -cpu max or -cpu host; it's always false for other classes. Therefore it can be turned into a field in the X86CPUClass. Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qom: Have class_init() take a const data argumentPhilippe Mathieu-Daudé2025-04-251-1/+1
| | | | | | | | | | Mechanical change using gsed, then style manually adapted to pass checkpatch.pl script. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250424194905.82506-4-philmd@linaro.org>
* accel: Rename 'hw/core/accel-cpu.h' -> 'accel/accel-cpu-target.h'Philippe Mathieu-Daudé2025-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | AccelCPUClass is for accelerator to initialize target specific features of a vCPU. Not really related to hardware emulation, rename "hw/core/accel-cpu.h" as "accel/accel-cpu-target.h" (using the explicit -target suffix). More importantly, target specific header often access the target specific definitions which are in each target/FOO/cpu.h header, usually included generically as "cpu.h" relative to target/FOO/. However, there is already a "cpu.h" in hw/core/ which takes precedence. This change allows "accel-cpu-target.h" to include a target "cpu.h". Mechanical change doing: $ git mv include/hw/core/accel-cpu.h \ include/accel/accel-cpu-target.h $ sed -i -e 's,hw/core/accel-cpu.h,accel/accel-cpu-target.h,' \ $(git grep -l hw/core/accel-cpu.h) and renaming header guard 'ACCEL_CPU_TARGET_H'. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250123234415.59850-12-philmd@linaro.org>
* include: Rename sysemu/ -> system/Philippe Mathieu-Daudé2024-12-201-1/+1
| | | | | | | | | | | | | Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
* target/i386: do not rely on ExtSaveArea for accelerator-supported XCR0 bitsPaolo Bonzini2024-10-311-4/+0
| | | | | | | | | | | | | | | | | Right now, QEMU is using the "feature" and "bits" fields of ExtSaveArea to query the accelerator for the support status of extended save areas. This is a problem for AVX10, which attaches two feature bits (AVX512F and AVX10) to the same extended save states. To keep the AVX10 hacks to the minimum, limit usage of esa->features and esa->bits. Instead, just query the accelerator for the 0xD leaf. Do it in common code and clear esa->size if an extended save state is unsupported. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20241031085233.425388-3-tao1.su@linux.intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: pass X86CPU to x86_cpu_get_supported_feature_wordPaolo Bonzini2024-07-031-1/+1
| | | | | | | | | | | | | | This allows modifying the bits in "-cpu max"/"-cpu host" depending on the guest CPU vendor (which, at least by default, is the host vendor in the case of KVM). For example, machine check architecture differs between Intel and AMD, and bits from AMD should be dropped when configuring the guest for an Intel model. Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: John Allen <john.allen@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Advertise MWAIT iff host supportsZide Chen2024-06-301-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | host_cpu_realizefn() sets CPUID_EXT_MONITOR without consulting host/KVM capabilities. This may cause problems: - If MWAIT/MONITOR is not available on the host, advertising this feature to the guest and executing MWAIT/MONITOR from the guest triggers #UD and the guest doesn't boot. This is because typically #UD takes priority over VM-Exit interception checks and KVM doesn't emulate MONITOR/MWAIT on #UD. - If KVM doesn't support KVM_X86_DISABLE_EXITS_MWAIT, MWAIT/MONITOR from the guest are intercepted by KVM, which is not what cpu-pm=on intends to do. In these cases, MWAIT/MONITOR should not be exposed to the guest. The logic in kvm_arch_get_supported_cpuid() to handle CPUID_EXT_MONITOR is correct and sufficient, and we can't set CPUID_EXT_MONITOR after x86_cpu_filter_features(). This was not an issue before commit 662175b91ff ("i386: reorder call to cpu_exec_realizefn") because the feature added in the accel-specific realizefn could be checked against host availability and filtered out. Additionally, it seems not a good idea to handle guest CPUID leaves in host_cpu_realizefn(), and this patch merges host_cpu_enable_cpu_pm() into kvm_cpu_realizefn(). Fixes: f5cc5a5c1686 ("i386: split cpu accelerators from cpu.c, using AccelCPUClass") Fixes: 662175b91ff2 ("i386: reorder call to cpu_exec_realizefn") Signed-off-by: Zide Chen <zide.chen@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'Philippe Mathieu-Daudé2024-06-191-2/+1
| | | | | | | | | | | | x86_cpu_change_kvm_default() was only used out of kvm-cpu.c by the pc-i440fx-2.1 machine, which got removed. Make it static, and remove its declaration. "kvm-cpu.h" is now empty, remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240617071118.60464-10-philmd@linaro.org>
* kvm: add support for guest physical bitsGerd Hoffmann2024-04-181-8/+42
| | | | | | | | | | | | | | | | | | Query kvm for supported guest physical address bits, in cpuid function 80000008, eax[23:16]. Usually this is identical to host physical address bits. With NPT or EPT being used this might be restricted to 48 (max 4-level paging address space size) even if the host cpu supports more physical address bits. When set pass this to the guest, using cpuid too. Guest firmware can use this to figure how big the usable guest physical address space is, so PCI bar mapping are actually reachable. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240318155336.156197-2-kraxel@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386/kvm: Correct comment in kvm_cpu_realize()Philippe Mathieu-Daudé2023-11-071-0/+1
| | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230918160257.30127-4-philmd@linaro.org>
* accel: Rename accel_cpu_realize() -> accel_cpu_common_realize()Philippe Mathieu-Daudé2023-10-031-1/+1
| | | | | | | | | | | | accel_cpu_realize() is a generic function working with CPUs from any target. Rename it using '_common_' to emphasis it is not target specific. Suggested-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231003123026.99229-4-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* accel: Rename AccelCPUClass::cpu_realizefn() -> cpu_target_realize()Philippe Mathieu-Daudé2023-10-031-1/+1
| | | | | | | | | | The AccelCPUClass::cpu_realizefn handler is meant for target specific code, rename it using '_target_' to emphasis it. Suggested-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231003123026.99229-3-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* accel: Rename accel_cpu_realizefn() -> accel_cpu_realize()Philippe Mathieu-Daudé2023-10-031-1/+1
| | | | | | | | | | We use the '*fn' suffix for handlers, this is a public method. Drop the suffix. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20231003123026.99229-2-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* target/i386: Fix sanity check on max APIC ID / X2APIC enablementDavid Woodhouse2022-05-161-1/+1
| | | | | | | | | | | | | | | | | | | The check on x86ms->apic_id_limit in pc_machine_done() had two problems. Firstly, we need KVM to support the X2APIC API in order to allow IRQ delivery to APICs >= 255. So we need to call/check kvm_enable_x2apic(), which was done elsewhere in *some* cases but not all. Secondly, microvm needs the same check. So move it from pc_machine_done() to x86_cpus_init() where it will work for both. The check in kvm_cpu_instance_init() is now redundant and can be dropped. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Acked-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20220314142544.150555-1-dwmw2@infradead.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* KVM: x86: workaround invalid CPUID[0xD,9] info on some AMD processorsPaolo Bonzini2022-03-231-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Some AMD processors expose the PKRU extended save state even if they do not have the related PKU feature in CPUID. Worse, when they do they report a size of 64, whereas the expected size of the PKRU extended save state is 8, therefore the esa->size == eax assertion does not hold. The state is already ignored by KVM_GET_SUPPORTED_CPUID because it was not enabled in the host XCR0. However, QEMU kvm_cpu_xsave_init() runs before QEMU invokes arch_prctl() to enable dynamically-enabled save states such as XTILEDATA, and KVM_GET_SUPPORTED_CPUID hides save states that have yet to be enabled. Therefore, kvm_cpu_xsave_init() needs to consult the host CPUID instead of KVM_GET_SUPPORTED_CPUID, and dies with an assertion failure. When setting up the ExtSaveArea array to match the host, ignore features that KVM does not report as supported. This will cause QEMU to skip the incorrect CPUID leaf instead of tripping the assertion. Closes: https://gitlab.com/qemu-project/qemu/-/issues/916 Reported-by: Daniel P. Berrangé <berrange@redhat.com> Analyzed-by: Yang Zhong <yang.zhong@intel.com> Reported-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* x86: Grant AMX permission for guestYang Zhong2022-03-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Kernel allocates 4K xstate buffer by default. For XSAVE features which require large state component (e.g. AMX), Linux kernel dynamically expands the xstate buffer only after the process has acquired the necessary permissions. Those are called dynamically- enabled XSAVE features (or dynamic xfeatures). There are separate permissions for native tasks and guests. Qemu should request the guest permissions for dynamic xfeatures which will be exposed to the guest. This only needs to be done once before the first vcpu is created. KVM implemented one new ARCH_GET_XCOMP_SUPP system attribute API to get host side supported_xcr0 and Qemu can decide if it can request dynamically enabled XSAVE features permission. https://lore.kernel.org/all/20220126152210.3044876-1-pbonzini@redhat.com/ Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Jing Liu <jing2.liu@intel.com> Message-Id: <20220217060434.52460-4-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* x86: Fix the 64-byte boundary enumeration for extended stateJing Liu2022-03-151-0/+1
| | | | | | | | | | | | | | | | | | The extended state subleaves (EAX=0Dh, ECX=n, n>1).ECX[1] indicate whether the extended state component locates on the next 64-byte boundary following the preceding state component when the compacted format of an XSAVE area is used. Right now, they are all zero because no supported component needed the bit to be set, but the upcoming AMX feature will use it. Fix the subleaves value according to KVM's supported cpuid. Signed-off-by: Jing Liu <jing2.liu@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20220217060434.52460-2-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: do not call cpudef-only models functions for max, host, baseClaudio Fontana2021-07-231-49/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some cpu properties have to be set only for cpu models in builtin_x86_defs, registered with x86_register_cpu_model_type, and not for cpu models "base", "max", and the subclass "host". These properties are the ones set by function x86_cpu_apply_props, (also including kvm_default_props, tcg_default_props), and the "vendor" property for the KVM and HVF accelerators. After recent refactoring of cpu, which also affected these properties, they were instead set unconditionally for all x86 cpus. This has been detected as a bug with Nested on AMD with cpu "host", as svm was not turned on by default, due to the wrongful setting of kvm_default_props via x86_cpu_apply_props, which set svm to "off". Rectify the bug introduced in commit "i386: split cpu accelerators" and document the functions that are builtin_x86_defs-only. Signed-off-by: Claudio Fontana <cfontana@suse.de> Tested-by: Alexander Bulekov <alxndr@bu.edu> Fixes: f5cc5a5c ("i386: split cpu accelerators from cpu.c,"...) Resolves: https://gitlab.com/qemu-project/qemu/-/issues/477 Message-Id: <20210723112921.12637-1-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Populate x86_ext_save_areas offsets using cpuid where possibleDavid Edmondson2021-07-061-0/+30
| | | | | | | | | | Rather than relying on the X86XSaveArea structure definition, determine the offset of XSAVE state areas using CPUID leaf 0xd where possible (KVM and HVF). Signed-off-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20210705104632.2902400-8-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: reorder call to cpu_exec_realizefnClaudio Fontana2021-06-041-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i386 realizefn code is sensitive to ordering, and recent commits aimed at refactoring it, splitting accelerator-specific code, broke assumptions which need to be fixed. We need to: * process hyper-v enlightements first, as they assume features not to be expanded * only then, expand features * after expanding features, attempt to check them and modify them in the accel-specific realizefn code called by cpu_exec_realizefn(). * after the framework has been called via cpu_exec_realizefn, the code can check for what has or hasn't been set by accel-specific code, or extend its results, ie: - check and evenually set code_urev default - modify cpu->mwait after potentially being set from host CPUID. - finally check for phys_bits assuming all user and accel-specific adjustments have already been taken into account. Fixes: f5cc5a5c ("i386: split cpu accelerators from cpu.c"...) Fixes: 30565f10 ("cpu: call AccelCPUClass::cpu_realizefn in"...) Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210603123001.17843-2-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Document when features can be added to kvm_default_propsEduardo Habkost2021-05-311-0/+5
| | | | | | | | | | | | It's very easy to mistakenly extend kvm_default_props to include features that require a kernel version that's too recent. Add a comment warning about that, pointing to the documentation file where the minimum kernel version for KVM is documented. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200925211021.4158567-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* accel-cpu: make cpu_realizefn return a boolClaudio Fontana2021-05-101-2/+2
| | | | | | | | | | | | | | | | | | | | | overall, all devices' realize functions take an Error **errp, but return void. hw/core/qdev.c code, which realizes devices, therefore does: local_err = NULL; dc->realize(dev, &local_err); if (local_err != NULL) { goto fail; } However, we can improve at least accel_cpu to return a meaningful bool value. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210322132800.7470-9-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: split cpu accelerators from cpu.c, using AccelCPUClassClaudio Fontana2021-05-101-0/+151
i386 is the first user of AccelCPUClass, allowing to split cpu.c into: cpu.c cpuid and common x86 cpu functionality host-cpu.c host x86 cpu functions and "host" cpu type kvm/kvm-cpu.c KVM x86 AccelCPUClass hvf/hvf-cpu.c HVF x86 AccelCPUClass tcg/tcg-cpu.c TCG x86 AccelCPUClass Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [claudio]: Rebased on commit b8184135 ("target/i386: allow modifying TCG phys-addr-bits") Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210322132800.7470-5-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>