aboutsummaryrefslogtreecommitdiff
path: root/target/i386/cpu.c
AgeCommit message (Collapse)Author
2021-09-30i386: Update SGX CPUID info according to hardware/KVM/user inputSean Christopherson
Expose SGX to the guest if and only if KVM is enabled and supports virtualization of SGX. While the majority of ENCLS can be emulated to some degree, because SGX uses a hardware-based root of trust, the attestation aspects of SGX cannot be emulated in software, i.e. ultimately emulation will fail as software cannot generate a valid quote/report. The complexity of partially emulating SGX in Qemu far outweighs the value added, e.g. an SGX specific simulator for userspace applications can emulate SGX for development and testing purposes. Note, access to the PROVISIONKEY is not yet advertised to the guest as KVM blocks access to the PROVISIONKEY by default and requires userspace to provide additional credentials (via ioctl()) to expose PROVISIONKEY. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-13-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add get/set/migrate support for SGX_LEPUBKEYHASH MSRsSean Christopherson
On real hardware, on systems that supports SGX Launch Control, those MSRs are initialized to digest of Intel's signing key; on systems that don't support SGX Launch Control, those MSRs are not available but hardware always uses digest of Intel's signing key in EINIT. KVM advertises SGX LC via CPUID if and only if the MSRs are writable. Unconditionally initialize those MSRs to digest of Intel's signing key when CPU is realized and reset to reflect the fact. This avoids potential bug in case kvm_arch_put_registers() is called before kvm_arch_get_registers() is called, in which case guest's virtual SGX_LEPUBKEYHASH MSRs will be set to 0, although KVM initializes those to digest of Intel's signing key by default, since KVM allows those MSRs to be updated by Qemu to support live migration. Save/restore the SGX Launch Enclave Public Key Hash MSRs if SGX Launch Control (LC) is exposed to the guest. Likewise, migrate the MSRs if they are writable by the guest. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-11-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_1_EAXSean Christopherson
CPUID leaf 12_1_EAX is an Intel-defined feature bits leaf enumerating the platform's SGX capabilities that may be utilized by an enclave, e.g. whether or not an enclave can gain access to the provision key. Currently there are six capabilities: - INIT: set when the enclave has has been initialized by EINIT. Cannot be set by software, i.e. forced to zero in CPUID. - DEBUG: permits a debugger to read/write into the enclave. - MODE64BIT: the enclave runs in 64-bit mode - PROVISIONKEY: grants has access to the provision key - EINITTOKENKEY: grants access to the EINIT token key, i.e. the enclave can generate EINIT tokens - KSS: Key Separation and Sharing enabled for the enclave. Note that the entirety of CPUID.0x12.0x1, i.e. all registers, enumerates the allowed ATTRIBUTES (128 bits), but only bits 31:0 are directly exposed to the user (via FEAT_12_1_EAX). Bits 63:32 are currently all reserved and bits 127:64 correspond to the allowed XSAVE Feature Request Mask, which is calculated based on other CPU features, e.g. XSAVE, MPX, AVX, etc... and is not exposed to the user. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-10-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_0_EBXSean Christopherson
CPUID leaf 12_0_EBX is an Intel-defined feature bits leaf enumerating the platform's SGX extended capabilities. Currently there is a single capabilitiy: - EXINFO: record information about #PFs and #GPs in the enclave's SSA Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-9-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_0_EAXSean Christopherson
CPUID leaf 12_0_EAX is an Intel-defined feature bits leaf enumerating the CPU's SGX capabilities, e.g. supported SGX instruction sets. Currently there are four enumerated capabilities: - SGX1 instruction set, i.e. "base" SGX - SGX2 instruction set for dynamic EPC management - ENCLV instruction set for VMM oversubscription of EPC - ENCLS-C instruction set for thread safe variants of ENCLS Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-8-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add primary SGX CPUID and MSR definesSean Christopherson
Add CPUID defines for SGX and SGX Launch Control (LC), as well as defines for their associated FEATURE_CONTROL MSR bits. Define the Launch Enclave Public Key Hash MSRs (LE Hash MSRs), which exist when SGX LC is present (in CPUID), and are writable when SGX LC is enabled (in FEATURE_CONTROL). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-7-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-13target/i386: Added VGIF V_IRQ masking capabilityLara Lazier
VGIF provides masking capability for when virtual interrupts are taken. (APM2) Signed-off-by: Lara Lazier <laramglazier@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-13target/i386: Moved int_ctl into CPUX86State structureLara Lazier
Moved int_ctl into the CPUX86State structure. It removes some unnecessary stores and loads, and prepares for tracking the vIRQ state even when it is masked due to vGIF. Signed-off-by: Lara Lazier <laramglazier@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-13target/i386: Added VGIF featureLara Lazier
VGIF allows STGI and CLGI to execute in guest mode and control virtual interrupts in guest mode. When the VGIF feature is enabled then: * executing STGI in the guest sets bit 9 of the VMCB offset 60h. * executing CLGI in the guest clears bit 9 of the VMCB offset 60h. Signed-off-by: Lara Lazier <laramglazier@gmail.com> Message-Id: <20210730070742.9674-1-laramglazier@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-13target/i386: VMRUN and VMLOAD canonicalizationsLara Lazier
APM2 requires that VMRUN and VMLOAD canonicalize (sign extend to 63 from 48/57) all base addresses in the segment registers that have been respectively loaded. Signed-off-by: Lara Lazier <laramglazier@gmail.com> Message-Id: <20210804113058.45186-1-laramglazier@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-08-25i386/cpu: Remove AVX_VNNI feature from Cooperlake cpu modelYang Zhong
The AVX_VNNI feature is not in Cooperlake platform, remove it from cpu model. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210820054611.84303-1-yang.zhong@intel.com> Fixes: c1826ea6a052 ("i386/cpu: Expose AVX_VNNI instruction to guest") Cc: qemu-stable@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-08-25target/i386: Remove split lock detect in Snowridge CPU modelChenyi Qiang
At present, there's no mechanism intelligent enough to virtualize split lock detection correctly. Remove it in Snowridge CPU model to avoid the feature exposure. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20210630012053.10098-1-chenyi.qiang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-27docs: Update path that mentions deprecated.rstMao Zhongyi
Missed in commit f3478392 "docs: Move deprecation, build and license info out of system/" Signed-off-by: Mao Zhongyi <maozhongyi@cmss.chinamobile.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210723065828.1336760-1-maozhongyi@cmss.chinamobile.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-23i386: do not call cpudef-only models functions for max, host, baseClaudio Fontana
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>
2021-07-13target/i386: Fix cpuid level for AMDzhenwei pi
A AMD server typically has cpuid level 0x10(test on Rome/Milan), it should not be changed to 0x1f in multi-dies case. * to maintain compatibility with older machine types, only implement this change when the CPU's "x-vendor-cpuid-only" property is false Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: zhenwei pi <pizhenwei@bytedance.com> Fixes: a94e1428991 (target/i386: Add CPUID.1F generation support for multi-dies PCMachine) Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-Id: <20210708170641.49410-1-michael.roth@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13target/i386: suppress CPUID leaves not defined by the CPU vendorMichael Roth
Currently all built-in CPUs report cache information via CPUID leaves 2 and 4, but these have never been defined for AMD. In the case of SEV-SNP this can cause issues with CPUID enforcement. Address this by allowing CPU types to suppress these via a new "x-vendor-cpuid-only" CPU property, which is true by default, but switched off for older machine types to maintain compatibility. Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: zhenwei pi <pizhenwei@bytedance.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-Id: <20210708003623.18665-1-michael.roth@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: expand Hyper-V features during CPU feature expansion timeVitaly Kuznetsov
To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we need to expand and set the corresponding CPUID leaves early. Modify x86_cpu_get_supported_feature_word() to call newly intoduced Hyper-V specific kvm_hv_get_supported_cpuid() instead of kvm_arch_get_supported_cpuid(). We can't use kvm_arch_get_supported_cpuid() as Hyper-V specific CPUID leaves intersect with KVM's. Note, early expansion will only happen when KVM supports system wide KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID). Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-6-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-06target/i386: Populate x86_ext_save_areas offsets using cpuid where possibleDavid Edmondson
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>
2021-07-06target/i386: Make x86_ext_save_areas visible outside cpu.cDavid Edmondson
Provide visibility of the x86_ext_save_areas array and associated type outside of cpu.c. Signed-off-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20210705104632.2902400-6-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-25target/i386: kvm: add support for TSC scalingPaolo Bonzini
Linux 5.14 will add support for nested TSC scaling. Add the corresponding feature in QEMU; to keep support for existing kernels, do not add it to any processor yet. The handling of the VMCS enumeration MSR is ugly; once we have more than one case, we may want to add a table to check VMX features against. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-04i386: run accel_cpu_instance_init as post_initClaudio Fontana
This fixes host and max cpu initialization, by running the accel cpu initialization only after all instance init functions are called for all X86 cpu subclasses. The bug this is fixing is related to the "max" and "host" i386 cpu subclasses, which set cpu->max_features, which is then used at cpu realization time. In order to properly split the accel-specific max features code that needs to be executed at cpu instance initialization time, we cannot call the accel cpu initialization at the end of the x86 base class initialization, or we will have no way to specialize "max features" cpu behavior, overriding the "max" cpu class defaults, and checking for the "max features" flag itself. This patch moves the accel-specific cpu instance initialization to after all x86 cpu instance code has been executed, including subclasses, so that proper initialization of cpu "host" and "max" can be restored. Fixes: f5cc5a5c ("i386: split cpu accelerators from cpu.c,"...) Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210603123001.17843-3-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-04i386: reorder call to cpu_exec_realizefnClaudio Fontana
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>
2021-05-31i386: drop FEAT_HYPERV feature leavesVitaly Kuznetsov
Hyper-V feature leaves are weird. We have some of them in feature_word_info[] array but we don't use feature_word_info magic to enable them. Neither do we use feature_dependencies[] mechanism to validate the configuration as it doesn't allign well with Hyper-V's many-to-many dependency chains. Some of the feature leaves hold not only feature bits, but also values. E.g. FEAT_HV_NESTED_EAX contains both features and the supported Enlightened VMCS range. Hyper-V features are already represented in 'struct X86CPU' with uint64_t hyperv_features so duplicating them in env->features adds little (or zero) benefits. THe other half of Hyper-V emulation features is also stored with values in hyperv_vendor_id[], hyperv_limits[],... so env->features[] is already incomplete. Remove Hyper-V feature leaves from env->features[] completely. kvm_hyperv_properties[] is converted to using raw CPUID func/reg pairs for features, this allows us to get rid of hv_cpuid_get_fw() conversion. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-8-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: keep hyperv_vendor string up-to-dateVitaly Kuznetsov
When cpu->hyperv_vendor is not set manually we default to "Microsoft Hv" and in 'hv_passthrough' mode we get the information from the host. This information is stored in cpu->hyperv_vendor_id[] array but we don't update cpu->hyperv_vendor string so e.g. QMP's query-cpu-model-expansion output is incorrect. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-2-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: use better matching family/model/stepping for 'max' CPUDaniel P. Berrangé
The 'max' CPU under TCG currently reports a family/model/stepping that approximately corresponds to an AMD K7 vintage architecture. The K7 series predates the introduction of 64-bit support by AMD in the K8 series. This has been reported to lead to LLVM complaints about generating 64-bit code for a 32-bit CPU target LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! It appears LLVM looks at the family/model/stepping, despite qemu64 reporting it is 64-bit capable. This patch changes 'max' to report a CPUID with the family, model and stepping taken from a AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ which is one of the first 64-bit AMD CPUs. Closes https://gitlab.com/qemu-project/qemu/-/issues/191 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210507133650.645526-3-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: use better matching family/model/stepping for 'qemu64' CPUDaniel P. Berrangé
The 'qemu64' CPUID currently reports a family/model/stepping that approximately corresponds to an AMD K7 vintage architecture. The K7 series predates the introduction of 64-bit support by AMD in the K8 series. This has been reported to lead to LLVM complaints about generating 64-bit code for a 32-bit CPU target LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! It appears LLVM looks at the family/model/stepping, despite qemu64 reporting it is 64-bit capable. This patch changes 'qemu64' to report a CPUID with the family, model and stepping taken from a AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ which is one of the first 64-bit AMD CPUs. Closes https://gitlab.com/qemu-project/qemu/-/issues/191 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210507133650.645526-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386/cpu: Constify X86CPUDefinitionPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210503173524.833052-3-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386/cpu: Constify CPUCachesPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210503173524.833052-2-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386: Add CPU model versions supporting 'xsaves'Vitaly Kuznetsov
Hyper-V 2016 refuses to boot on Skylake+ CPU models because they lack 'xsaves'/'vmx-xsaves' features and this diverges from real hardware. The same issue emerges with AMD "EPYC" CPU model prior to version 3 which got 'xsaves' added. EPYC-Rome/EPYC-Milan CPU models have 'xsaves' enabled from the very beginning so the comment blaming KVM to explain why other CPUs lack 'xsaves' is likely outdated. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210412073952.860944-1-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-28Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210526' ↵Peter Maydell
into staging Adjust types for some memory access functions. Reduce inclusion of tcg headers. Fix watchpoints vs replay. Fix tcg/aarch64 roli expansion. Introduce SysemuCPUOps structure. # gpg: Signature made Thu 27 May 2021 00:43:54 BST # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth-gitlab/tags/pull-tcg-20210526: (31 commits) hw/core: Constify TCGCPUOps target/mips: Fold jazz behaviour into mips_cpu_do_transaction_failed cpu: Move CPUClass::get_paging_enabled to SysemuCPUOps cpu: Move CPUClass::get_memory_mapping to SysemuCPUOps cpu: Move CPUClass::get_phys_page_debug to SysemuCPUOps cpu: Move CPUClass::asidx_from_attrs to SysemuCPUOps cpu: Move CPUClass::write_elf* to SysemuCPUOps cpu: Move CPUClass::get_crash_info to SysemuCPUOps cpu: Move CPUClass::virtio_is_big_endian to SysemuCPUOps cpu: Move CPUClass::vmsd to SysemuCPUOps cpu: Introduce SysemuCPUOps structure cpu: Move AVR target vmsd field from CPUClass to DeviceClass cpu: Rename CPUClass vmsd -> legacy_vmsd cpu: Assert DeviceClass::vmsd is NULL on user emulation cpu: Directly use get_memory_mapping() fallback handlers in place cpu: Directly use get_paging_enabled() fallback handlers in place cpu: Directly use cpu_write_elf*() fallback handlers in place cpu: Introduce cpu_virtio_is_big_endian() cpu: Un-inline cpu_get_phys_page_debug and cpu_asidx_from_attrs cpu: Split as cpu-common / cpu-sysemu ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-26cpu: Move CPUClass::get_paging_enabled to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-23-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_memory_mapping to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-22-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_phys_page_debug to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-21-f4bug@amsat.org> [rth: Drop declaration movement from target/*/cpu.h] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::asidx_from_attrs to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-20-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::write_elf* to SysemuCPUOpsPhilippe Mathieu-Daudé
The write_elf*() handlers are used to dump vmcore images. This feature is only meaningful for system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-19-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_crash_info to SysemuCPUOpsPhilippe Mathieu-Daudé
cpu_get_crash_info() is called on GUEST_PANICKED events, which only occur in system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-18-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::vmsd to SysemuCPUOpsPhilippe Mathieu-Daudé
Migration is specific to system emulation. - Move the CPUClass::vmsd field to SysemuCPUOps, - restrict VMSTATE_CPU() macro to sysemu, - vmstate_dummy is now unused, remove it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-16-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Introduce SysemuCPUOps structurePhilippe Mathieu-Daudé
Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Rename CPUClass vmsd -> legacy_vmsdPhilippe Mathieu-Daudé
Quoting Peter Maydell [*]: There are two ways to handle migration for a CPU object: (1) like any other device, so it has a dc->vmsd that covers migration for the whole object. As usual for objects that are a subclass of a parent that has state, the first entry in the VMStateDescription field list is VMSTATE_CPU(), which migrates the cpu_common fields, followed by whatever the CPU's own migration fields are. (2) a backwards-compatible mechanism for CPUs that were originally migrated using manual "write fields to the migration stream structures". The on-the-wire migration format for those is based on the 'env' pointer (which isn't a QOM object), and the cpu_common part of the migration data is elsewhere. cpu_exec_realizefn() handles both possibilities: * for type 1, dc->vmsd is set and cc->vmsd is not, so cpu_exec_realizefn() does nothing, and the standard "register dc->vmsd for a device" code does everything needed * for type 2, dc->vmsd is NULL and so we register the vmstate_cpu_common directly to handle the cpu-common fields, and the cc->vmsd to handle the per-CPU stuff You can't change a CPU from one type to the other without breaking migration compatibility, which is why some guest architectures are stuck on the cc->vmsd form. New targets should use dc->vmsd. To avoid new targets to start using type (2), rename cc->vmsd as cc->legacy_vmsd. The correct field to implement is dc->vmsd (the DeviceClass one). See also commit b170fce3dd0 ("cpu: Register VMStateDescription through CPUState") for historic background. [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg800849.html Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210517105140.1062037-13-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26i386/cpu: Expose AVX_VNNI instruction to guestYang Zhong
Expose AVX (VEX-encoded) versions of the Vector Neural Network Instructions to guest. The bit definition: CPUID.(EAX=7,ECX=1):EAX[bit 4] AVX_VNNI The following instructions are available when this feature is present in the guest. 1. VPDPBUS: Multiply and Add Unsigned and Signed Bytes 2. VPDPBUSDS: Multiply and Add Unsigned and Signed Bytes with Saturation 3. VPDPWSSD: Multiply and Add Signed Word Integers 4. VPDPWSSDS: Multiply and Add Signed Integers with Saturation As for the kvm related code, please reference Linux commit id 1085a6b585d7. The release document ref below link: https://software.intel.com/content/www/us/en/develop/download/\ intel-architecture-instruction-set-extensions-programming-reference.html Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210407015609.22936-1-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-10i386: split off sysemu part of cpu.cClaudio Fontana
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210322132800.7470-19-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-10accel: introduce new accessor functionsClaudio Fontana
avoid open coding the accesses to cpu->accel_cpu interfaces, and instead introduce: accel_cpu_instance_init, accel_cpu_realizefn to be used by the targets/ initfn code, and by cpu_exec_realizefn respectively. 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> Message-Id: <20210322132800.7470-7-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-10cpu: call AccelCPUClass::cpu_realizefn in cpu_exec_realizefnClaudio Fontana
move the call to accel_cpu->cpu_realizefn to the general cpu_exec_realizefn from target/i386, so it does not need to be called for every target explicitly as we enable more targets. 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> Message-Id: <20210322132800.7470-6-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-10i386: split cpu accelerators from cpu.c, using AccelCPUClassClaudio Fontana
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>
2021-04-09i386: Add missing cpu feature bits in EPYC-Rome modelBabu Moger
Found the following cpu feature bits missing from EPYC-Rome model. ibrs : Indirect Branch Restricted Speculation ssbd : Speculative Store Bypass Disable These new features will be added in EPYC-Rome-v2. The -cpu help output after the change. x86 EPYC-Rome (alias configured by machine type) x86 EPYC-Rome-v1 AMD EPYC-Rome Processor x86 EPYC-Rome-v2 AMD EPYC-Rome Processor Reported-by: Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <161478622280.16275.6399866734509127420.stgit@bmoger-ubuntu> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-03-19target/i386: allow modifying TCG phys-addr-bitsPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-03-09Various spelling fixesMichael Tokarev
An assorted set of spelling fixes in various places. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210309111510.79495-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-25target/i386: Add bus lock debug exception supportChenyi Qiang
Bus lock debug exception is a feature that can notify the kernel by generate an #DB trap after the instruction acquires a bus lock when CPL>0. This allows the kernel to enforce user application throttling or mitigations. This feature is enumerated via CPUID.(EAX=7,ECX=0).ECX[bit 24]. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20210202090224.13274-1-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-25target/i386: update to show preferred boolean syntax for -cpuDaniel P. Berrangé
The preferred syntax is to use "foo=on|off", rather than a bare "+foo" or "-foo" Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-11-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-18i386: Add the support for AMD EPYC 3rd generation processorsBabu Moger
Adds the support for AMD 3rd generation processors. The model display for the new processor will be EPYC-Milan. Adds the following new feature bits on top of the feature bits from the first and second generation EPYC models. pcid : Process context identifiers support ibrs : Indirect Branch Restricted Speculation ssbd : Speculative Store Bypass Disable erms : Enhanced REP MOVSB/STOSB support fsrm : Fast Short REP MOVSB support invpcid : Invalidate processor context ID pku : Protection keys support svme-addr-chk : SVM instructions address check for #GP handling Depends on the following kernel commits: 14c2bf81fcd2 ("KVM: SVM: Fix #GP handling for doubly-nested virtualization") 3b9c723ed7cf ("KVM: SVM: Add support for SVM instruction address check change") 4aa2691dcbd3 ("8ce1c461188799d863398dd2865d KVM: x86: Factor out x86 instruction emulation with decoding") 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD") 9715092f8d7e ("KVM: X86: Move handling of INVPCID types to x86") 3f3393b3ce38 ("KVM: X86: Rename and move the function vmx_handle_memory_failure to x86.c") 830bd71f2c06 ("KVM: SVM: Remove set_cr_intercept, clr_cr_intercept and is_cr_intercept") 4c44e8d6c193 ("KVM: SVM: Add new intercept word in vmcb_control_area") c62e2e94b9d4 ("KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors") 9780d51dc2af ("KVM: SVM: Modify intercept_exceptions to generic intercepts") 30abaa88382c ("KVM: SVM: Change intercept_dr to generic intercepts") 03bfeeb988a9 ("KVM: SVM: Change intercept_cr to generic intercepts") c45ad7229d13 ("KVM: SVM: Introduce vmcb_(set_intercept/clr_intercept/_is_intercept)") a90c1ed9f11d ("(pcid) KVM: nSVM: Remove unused field") fa44b82eb831 ("KVM: x86: Move MPK feature detection to common code") 38f3e775e9c2 ("x86/Kconfig: Update config and kernel doc for MPK feature on AMD") 37486135d3a7 ("KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.c") Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <161290460478.11352.8933244555799318236.stgit@bmoger-ubuntu> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-18 00:48:28 +0000