aboutsummaryrefslogtreecommitdiff
path: root/target/i386/cpu.c
AgeCommit message (Collapse)Author
2019-06-11i386: "unavailable-features" QOM propertyEduardo Habkost
Add a "unavailable-features" QOM property to X86CPU objects that have the same semantics of "unavailable-features" on query-cpu-definitions. The new property has the same goal of "filtered-features", but is generic enough to let any kind of CPU feature to be listed there without relying on low level details like CPUID leaves or MSR numbers. Message-Id: <20190422234742.15780-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-06-11i386: x86_cpu_list_feature_names() functionEduardo Habkost
Extract feature name listing code from x86_cpu_class_check_missing_features(). It will be reused to return information about CPU filtered features at runtime. Message-Id: <20190422234742.15780-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-06-10cpu: Introduce cpu_set_cpustate_pointersRichard Henderson
Consolidate some boilerplate from foo_cpu_initfn. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-06-10target/i386: Use env_cpu, env_archcpuRichard Henderson
Cleanup in the boilerplate that each target must define. Replace x86_env_get_cpu with env_archcpu. The combination CPU(x86_env_get_cpu) should have used ENV_GET_CPU to begin; use env_cpu now. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-06-03i386: Enable IA32_MISC_ENABLE MWAIT bit when exposing mwait/monitorWanpeng Li
The CPUID.01H:ECX[bit 3] ought to mirror the value of the MSR IA32_MISC_ENABLE MWAIT bit and as userspace has control of them both, it is userspace's job to configure both bits to match on the initial setup. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Message-Id: <1557813999-9175-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-05-23Merge remote-tracking branch 'remotes/rth/tags/pull-rng-20190522' into stagingPeter Maydell
Introduce qemu_guest_getrandom. Use qemu_guest_getrandom in aspeed, nrf51, bcm2835, exynos4210 rng devices. Use qemu_guest_getrandom in target/ppc darn instruction. Support ARMv8.5-RNG extension. Support x86 RDRAND extension. Acked-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laurent Vivier <laurent@vivier.eu> # gpg: Signature made Wed 22 May 2019 19:36:43 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/tags/pull-rng-20190522: (25 commits) target/i386: Implement CPUID_EXT_RDRAND target/ppc: Use qemu_guest_getrandom for DARN target/ppc: Use gen_io_start/end around DARN target/arm: Implement ARMv8.5-RNG target/arm: Put all PAC keys into a structure hw/misc/exynos4210_rng: Use qemu_guest_getrandom hw/misc/bcm2835_rng: Use qemu_guest_getrandom_nofail hw/misc/nrf51_rng: Use qemu_guest_getrandom_nofail aspeed/scu: Use qemu_guest_getrandom_nofail linux-user: Remove srand call linux-user/aarch64: Use qemu_guest_getrandom for PAUTH keys linux-user: Use qemu_guest_getrandom_nofail for AT_RANDOM linux-user: Call qcrypto_init if not using -seed linux-user: Initialize pseudo-random seeds for all guest cpus cpus: Initialize pseudo-random seeds for all guest cpus util: Add qemu_guest_getrandom and associated routines ui/vnc: Use gcrypto_random_bytes for start_auth_vnc ui/vnc: Split out authentication_failed crypto: Change the qcrypto_random_bytes buffer type to void* crypto: Use getrandom for qcrypto_random_bytes ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-05-22target/i386: Implement CPUID_EXT_RDRANDRichard Henderson
We now have an interface for guest visible random numbers. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-21target/i386: add MDS-NO featurePaolo Bonzini
Microarchitectural Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which is available in various CPU internal buffers. Some Intel processors use the ARCH_CAP_MDS_NO bit in the IA32_ARCH_CAPABILITIES MSR to report that they are not vulnerable, make it available to guests. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20190516185320.28340-1-pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-21target/i386: define md-clear bitPaolo Bonzini
md-clear is a new CPUID bit which is set when microcode provides the mechanism to invoke a flush of various exploitable CPU buffers by invoking the VERW instruction. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20190515141011.5315-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-10target/i386: Convert to CPUClass::tlb_fillRichard Henderson
We do not support probing, but we do not need it yet either. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-04-25Pass through cache information for TOPOEXT CPUsStanislav Lanci
Signed-off-by: Stanislav Lanci <pixo@polepetko.eu> Message-Id: <20190416123833.60649-1-pixo@polepetko.eu> [ehabkost: removed redundant comment line] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-04-25i386: Add new Hygon 'Dhyana' CPU modelPu Wen
Add a new base CPU model called 'Dhyana' to model processors from Hygon Dhyana(family 18h), which derived from AMD EPYC(family 17h). The following features bits have been removed compare to AMD EPYC: aes, pclmulqdq, sha_ni The Hygon Dhyana support to KVM in Linux is already accepted upstream[1]. So add Hygon Dhyana support to Qemu is necessary to create Hygon's own CPU model. Reference: [1] https://git.kernel.org/tip/fec98069fb72fb656304a3e52265e0c2fc9adf87 Signed-off-by: Pu Wen <puwen@hygon.cn> Message-Id: <1555416373-28690-1-git-send-email-puwen@hygon.cn> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-04-18target: Simplify how the TARGET_cpu_list() printMarkus Armbruster
The various TARGET_cpu_list() take an fprintf()-like callback and a FILE * to pass to it. Their callers (vl.c's main() via list_cpus(), bsd-user/main.c's main(), linux-user/main.c's main()) all pass fprintf() and stdout. Thus, the flexibility provided by the (rather tiresome) indirection isn't actually used. Drop the callback, and call qemu_printf() instead. Calling printf() would also work, but would make the code unsuitable for monitor context without making it simpler. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190417191805.28198-10-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-03-20i386: Disable OSPKE on CPU model definitionsEduardo Habkost
Currently, the Cascadelake-Server, Icelake-Client, and Icelake-Server are always generating the following warning: qemu-system-x86_64: warning: \ host doesn't support requested feature: CPUID.07H:ECX [bit 4] This happens because OSPKE was never returned by GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word(). OSPKE is a runtime flag automatically set by the KVM module or by TCG code, was always cleared by x86_cpu_filter_features(), and was not supposed to appear on the CPU model table. Remove the OSPKE flag from the CPU model table entries, to avoid the bogus warning and avoid returning invalid feature data on query-cpu-* QMP commands. As OSPKE was always cleared by x86_cpu_filter_features(), this won't have any guest-visible impact. Include a test case that should detect the problem if we introduce a similar bug again. Fixes: c7a88b52f62b ("i386: Add new model of Cascadelake-Server") Fixes: 8a11c62da914 ("i386: Add new CPU model Icelake-{Server,Client}") Cc: Tao Xu <tao3.xu@intel.com> Cc: Robert Hoo <robert.hu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190319200515.14999-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20i386: Make arch_capabilities migratableEduardo Habkost
Now that kvm_arch_get_supported_cpuid() will only return arch_capabilities if QEMU is able to initialize the MSR properly, we know that the feature is safely migratable. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190125220606.4864-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-11i386: extended the cpuid_level when Intel PT is enabledLuwei Kang
Intel Processor Trace required CPUID[0x14] but the cpuid_level have no change when create a kvm guest with e.g. "-cpu qemu64,+intel-pt". Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Luwei Kang <luwei.kang@intel.com> Message-Id: <1548805979-12321-1-git-send-email-luwei.kang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-18qapi: make query-cpu-definitions depend on specific targetsMarc-André Lureau
It depends on TARGET_PPC || TARGET_ARM || TARGET_I386 || TARGET_S390X. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-15-armbru@redhat.com>
2019-02-18qapi: make query-cpu-model-expansion depend on s390 or x86Marc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-14-armbru@redhat.com>
2019-02-05gdbstub: Fix i386/x86_64 machine description and add control registersDoug Gale
The machine description we send is being (silently) thrown on the floor by GDB and GDB silently uses the default machine description, because the xml parse fails on <feature> nested within <feature>. Changes to the xml in qemu source code have no effect. In addition, the default machine description has fs_base, which fails to be retrieved, which breaks the whole register window. Add it and the other control registers. Signed-off-by: Doug Gale <doug16k@gmail.com> Message-Id: <20190124040457.2546-1-doug16k@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05Revert "i386: Add CPUID bit for PCONFIG"Robert Hoo
This reverts commit 5131dc433df54b37e8e918d8fba7fe10344e7a7b. For new instruction 'PCONFIG' will not be exposed to guest. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1545227081-213696-3-git-send-email-robert.hu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05i386: remove the 'INTEL_PT' CPUID bit from named CPU modelsPaolo Bonzini
Processor tracing is not yet implemented for KVM and it will be an opt in feature requiring a special module parameter. Disable it, because it is wrong to enable it by default and it is impossible that no one has ever used it. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05i386: remove the new CPUID 'PCONFIG' from Icelake-Server CPU modelRobert Hoo
PCONFIG is not available to guests; it must be specifically enabled using the PCONFIG_ENABLE execution control. Disable it, because no one can ever use it. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1545227081-213696-2-git-send-email-robert.hu@linux.intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-01-28i386: Enable NPT and NRIPSAVE for AMD CPUsVitaly Kuznetsov
Modern AMD CPUs support NPT and NRIPSAVE features and KVM exposes these when present. NRIPSAVE apeared somewhere in Opteron_G3 lifetime (e.g. QuadCore AMD Opteron 2378 has is but QuadCore AMD Opteron HE 2344 doesn't), NPT was introduced a bit earlier. Add the FEAT_SVM leaf to Opteron_G4/G5 and EPYC/EPYC-IBPB cpu models. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190121155051.5628-1-vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-28i386: Update stepping of Cascadelake-ServerTao Xu
Update the stepping from 5 to 6, in order that the Cascadelake-Server CPU model can support AVX512VNNI and MSR based features exposed by ARCH_CAPABILITIES. Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20181227024304.12182-2-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14i386/kvm: add a comment explaining why .feat_names are commented out for ↵Vitaly Kuznetsov
Hyper-V feature bits Hyper-V .feat_names are, unlike hardware features, commented out and it is not obvious why we do that. Document the current status quo. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20181221141604.16935-1-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14x86: host-phys-bits-limit optionEduardo Habkost
Some downstream distributions of QEMU set host-phys-bits=on by default. This worked very well for most use cases, because phys-bits really didn't have huge consequences. The only difference was on the CPUID data seen by guests, and on the handling of reserved bits. This changed in KVM commit 855feb673640 ("KVM: MMU: Add 5 level EPT & Shadow page table support"). Now choosing a large phys-bits value for a VM has bigger impact: it will make KVM use 5-level EPT even when it's not really necessary. This means using the host phys-bits value may not be the best choice. Management software could address this problem by manually configuring phys-bits depending on the size of the VM and the amount of MMIO address space required for hotplug. But this is not trivial to implement. However, there's another workaround that would work for most cases: keep using the host phys-bits value, but only if it's smaller than 48. This patch makes this possible by introducing a new "-cpu" option: "host-phys-bits-limit". Management software or users can make sure they will always use 4-level EPT using: "host-phys-bits=on,host-phys-bits-limit=48". This behavior is still not enabled by default because QEMU doesn't enable host-phys-bits=on by default. But users, management software, or downstream distributions may choose to change their defaults using the new option. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20181211192527.13254-1-ehabkost@redhat.com> [ehabkost: removed test code while some issues are addressed] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14target/i386: Disable MPX support on named CPU modelsPaolo Bonzini
MPX support is being phased out by Intel; GCC has dropped it, Linux is also going to do that. Even though KVM will have special code to support MPX after the kernel proper stops enabling it in XCR0, we probably also want to deprecate that in a few years. As a start, do not enable it by default for any named CPU model starting with the 4.0 machine types; this include Skylake, Icelake and Cascadelake. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20181220121100.21554-1-pbonzini@redhat.com> Reviewed-by:   Wainer dos Santos Moschetta <wainersm@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU modelsBorislav Petkov
The missing functionality was added ~3 years ago with the Linux commit 46896c73c1a4 ("KVM: svm: add support for RDTSCP") so reenable RDTSCP support on those CPU models. Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support (the real hardware doesn't have it. K8 got RDTSCP support with the NPT models, i.e., models >= 0x40). Document the host's minimum required kernel version, while at it. Signed-off-by: Borislav Petkov <bp@suse.de> Message-ID: <20181212200803.GG6653@zn.tnic> [ehabkost: moved compat properties code to pc.c] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and ↵Vitaly Kuznetsov
HV_CPUID_NESTED_FEATURES.EAX as feature words It was found that QMP users of QEMU (e.g. libvirt) may need HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in HV_CPUID_ENLIGHTMENT_INFO.EAX. HV_CPUID_NESTED_FEATURES.EAX is exposed for two reasons: convenience (we don't need to export it from hyperv_handle_properties() and as future-proof for Enlightened MSR-Bitmap, PV EPT invalidation and direct virtual flush features. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20181126135958.20956-1-vkuznets@redhat.com> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-07qdev-props: remove errp from GlobalPropertyMarc-André Lureau
All qdev_prop_register_global() set &error_fatal for errp, except '-rtc driftfix=slew', which arguably should also use &error_fatal, as otherwise failing to apply the property would only report a warning. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-12Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' ↵Peter Maydell
into staging x86 queue, 2018-12-11 * New CPU features: MOVDIRI, MOVDIR64B (Liu Jingqi); STIBP (Eduardo Habkost) * Fix clang build warning (Peter Maydell) # gpg: Signature made Tue 11 Dec 2018 20:52:56 GMT # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: i386: Add "stibp" flag name target/i386/kvm.c: Don't mark cpuid_data as QEMU_PACKED x86/cpu: Enable MOVDIR64B cpu feature x86/cpu: Enable MOVDIRI cpu feature Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-12-11i386: Add "stibp" flag nameEduardo Habkost
The STIBP flag may be supported by the host KVM module, so QEMU can allow it to be configured manually, and it can be exposed to guests when using "-cpu host". No additional migration code is required because the whole contents of spec_ctrl is already migrated in the "cpu/spec_ctrl" section. Corresponding KVM patch was submitted at: https://lore.kernel.org/lkml/20181205191956.31480-1-ehabkost@redhat.com/ Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20181210180250.31299-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-11x86/cpu: Enable MOVDIR64B cpu featureLiu Jingqi
MOVDIR64B moves 64-bytes as direct-store with 64-bytes write atomicity. Direct store is implemented by using write combining (WC) for writing data directly into memory without caching the data. The bit definition: CPUID.(EAX=7,ECX=0):ECX[bit 28] MOVDIR64B The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf Cc: Xu Tao <tao3.xu@intel.com> Signed-off-by: Liu Jingqi <jingqi.liu@intel.com> Message-Id: <1541488407-17045-3-git-send-email-jingqi.liu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-11x86/cpu: Enable MOVDIRI cpu featureLiu Jingqi
MOVDIRI moves doubleword or quadword from register to memory through direct store which is implemented by using write combining (WC) for writing data directly into memory without caching the data. The bit definition: CPUID.(EAX=7,ECX=0):ECX[bit 27] MOVDIRI The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf Cc: Xu Tao <tao3.xu@intel.com> Signed-off-by: Liu Jingqi <jingqi.liu@intel.com> Message-Id: <1541488407-17045-2-git-send-email-jingqi.liu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-11misc: fix spellingMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20181105135400.18366-1-marcandre.lureau@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2018-11-06x86: hv_evmcs CPU flag supportVitaly Kuznetsov
Adds a new CPU flag to enable the Enlightened VMCS KVM feature. QEMU enables KVM_CAP_HYPERV_ENLIGHTENED_VMCS and gets back the version to be advertised in lower 16 bits of CPUID.0x4000000A:EAX. Suggested-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20181022165506.30332-3-vkuznets@redhat.com> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-30i386: Add PKU on Skylake-Server CPU modelTao Xu
As the release document ref below link (page 13): https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf PKU is supported in Skylake Server (Only Server) and later, and on Intel(R) Xeon(R) Processor Scalable Family. So PKU is supposed to be in Skylake-Server CPU model. And PKU's CPUID has been exposed to QEMU. But PKU can't be find in Skylake-Server CPU model in the code. So this patch will fix this issue in Skylake-Server CPU model. Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <5014b57f834dcfa8fd3781504d98dcf063d54fde.1540801392.git.tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-30i386: Add new model of Cascadelake-ServerTao Xu
New CPU models mostly inherit features from ancestor Skylake-Server, while addin new features: AVX512_VNNI, Intel PT. SSBD support for speculative execution side channel mitigations. Note: On Cascadelake, some capabilities (RDCL_NO, IBRS_ALL, RSBA, SKIP_L1DFL_VMENTRY and SSB_NO) are enumerated by MSR. These features rely on MSR based feature support patch. Will be added later after that patch's in. http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00074.html Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20180919031122.28487-2-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-30x86: define a new MSR based feature word -- FEATURE_WORDS_ARCH_CAPABILITIESRobert Hoo
Note RSBA is specially treated -- no matter host support it or not, qemu pretends it is supported. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1539578845-37944-4-git-send-email-robert.hu@linux.intel.com> [ehabkost: removed automatic enabling of RSBA] Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-30x86: Data structure changes to support MSR based featuresRobert Hoo
Add FeatureWordType indicator in struct FeatureWordInfo. Change feature_word_info[] accordingly. Change existing functions that refer to feature_word_info[] accordingly. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1539578845-37944-3-git-send-email-robert.hu@linux.intel.com> [ehabkost: fixed hvf_enabled() case] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-30i386: correct cpu_x86_cpuid(0xd)Sebastian Andrzej Siewior
Intel SDM says for CPUID function 0DH, sub-function 0: | • ECX enumerates the size (in bytes) required by the XSAVE instruction for an | XSAVE area containing all the user state components supported by this | processor. | • EBX enumerates the size (in bytes) required by the XSAVE instruction for an | XSAVE area containing all the user state components corresponding to bits | currently set in XCR0. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Message-Id: <20180928104319.3296-1-bigeasy@linutronix.de> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-23Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2018-10-22' ↵Peter Maydell
into staging Error reporting patches for 2018-10-22 # gpg: Signature made Mon 22 Oct 2018 13:20:23 BST # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-error-2018-10-22: (40 commits) error: Drop bogus "use error_setg() instead" admonitions vpc: Fail open on bad header checksum block: Clean up bdrv_img_create()'s error reporting vl: Simplify call of parse_name() vl: Fix exit status for -drive format=help blockdev: Convert drive_new() to Error vl: Assert drive_new() does not fail in default_drive() fsdev: Clean up error reporting in qemu_fsdev_add() spice: Clean up error reporting in add_channel() tpm: Clean up error reporting in tpm_init_tpmdev() numa: Clean up error reporting in parse_numa() vnc: Clean up error reporting in vnc_init_func() ui: Convert vnc_display_init(), init_keyboard_layout() to Error ui/keymaps: Fix handling of erroneous include files vl: Clean up error reporting in device_init_func() vl: Clean up error reporting in parse_fw_cfg() vl: Clean up error reporting in mon_init_func() vl: Clean up error reporting in machine_set_property() vl: Clean up error reporting in chardev_init_func() qom: Clean up error reporting in user_creatable_add_opts_foreach() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-10-19cpus hw target: Use warn_report() & friends to report warningsMarkus Armbruster
Calling error_report() in a function that takes an Error ** argument is suspicious. Convert a few that are actually warnings to warn_report(). While there, split a warning consisting of multiple sentences to conform to conventions spelled out in warn_report()'s contract. Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Fam Zheng <famz@redhat.com> Cc: Wei Huang <wei@redhat.com> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20181017082702.5581-5-armbru@redhat.com>
2018-10-19hyperv: only add SynIC in compatible configurationsRoman Kagan
Certain configurations do not allow SynIC to be used in QEMU. In particular, - when hyperv_vpindex is off, SINT routes can't be used as they refer to the destination vCPU by vp_index - older KVM (which doesn't expose KVM_CAP_HYPERV_SYNIC2) zeroes out SynIC message and event pages on every msr load, breaking migration OTOH in-KVM users of SynIC -- SynIC timers -- do work in those configurations, and we shouldn't stop the guest from using them. To cover both scenarios, introduce an X86CPU property that makes CPU init code to skip creation of the SynIC object (and thus disables any SynIC use in QEMU) but keeps the KVM part of the SynIC working. The property is clear by default but is set via compat logic for older machine types. As a result, when hv_synic and a modern machine type are specified, QEMU will refuse to run unless vp_index is on and the kernel is recent enough. OTOH with an older machine type QEMU will run fine with hv_synic=on against an older kernel and/or without vp_index enabled but will disallow the in-QEMU uses of SynIC (in e.g. VMBus). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-4-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-19i386/kvm: add support for Hyper-V IPI sendVitaly Kuznetsov
Hyper-V PV IPI support is merged to KVM, enable the feature in Qemu. When enabled, this allows Windows guests to send IPIs to other vCPUs with a single hypercall even when there are >64 vCPUs in the request. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20181009130853.6412-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-02target/i386: unify masking of interruptsPaolo Bonzini
Interrupt handling depends on various flags in env->hflags or env->hflags2, and the exact detail were not exactly replicated between x86_cpu_has_work and x86_cpu_exec_interrupt. Create a new function that extracts the highest-priority non-masked interrupt, and use it in both functions. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-23i386: Fix arch_query_cpu_model_expansion() leakEduardo Habkost
Reported by Coverity: Error: RESOURCE_LEAK (CWE-772): [#def439] qemu-2.12.0/target/i386/cpu.c:3179: alloc_fn: Storage is returned from allocation function "qdict_new". qemu-2.12.0/qobject/qdict.c:34:5: alloc_fn: Storage is returned from allocation function "g_malloc0". qemu-2.12.0/qobject/qdict.c:34:5: var_assign: Assigning: "qdict" = "g_malloc0(4120UL)". qemu-2.12.0/qobject/qdict.c:37:5: return_alloc: Returning allocated memory "qdict". qemu-2.12.0/target/i386/cpu.c:3179: var_assign: Assigning: "props" = storage returned from "qdict_new()". qemu-2.12.0/target/i386/cpu.c:3217: leaked_storage: Variable "props" going out of scope leaks the storage it points to. This was introduced by commit b8097deb359b ("i386: Improve query-cpu-model-expansion full mode"). The leak is only theoretical: if ret->model->props is set to props, the qapi_free_CpuModelExpansionInfo() call will free props too in case of errors. The only way for this to not happen is if we enter the default branch of the switch statement, which would never happen because all CpuModelExpansionType values are being handled. It's still worth to change this to make the allocation logic easier to follow and make the Coverity error go away. To make everything simpler, initialize ret->model and ret->model->props earlier in the function. While at it, remove redundant check for !prop because prop is always initialized at the beginning of the function. Fixes: b8097deb359bbbd92592b9670adfe9e245b2d0bd Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180816183509.8231-1-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-16i386: Disable TOPOEXT by default on "-cpu host"Eduardo Habkost
Enabling TOPOEXT is always allowed, but it can't be enabled blindly by "-cpu host" because it may make guests crash if the rest of the cache topology information isn't provided or isn't consistent. This addresses the bug reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1613277 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180809221852.15285-1-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-08-16target-i386: adds PV_SEND_IPI CPUID feature bitWanpeng Li
Adds PV_SEND_IPI CPUID feature bit. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Message-Id: <1530526971-1812-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-08-16i386: Add new CPU model Icelake-{Server,Client}Robert Hoo
New CPU models mostly inherit features from ancestor Skylake, while addin new features: UMIP, New Instructions ( PCONIFIG (server only), WBNOINVD, AVX512_VBMI2, GFNI, AVX512_VNNI, VPCLMULQDQ, VAES, AVX512_BITALG), Intel PT and 5-level paging (Server only). As well as IA32_PRED_CMD, SSBD support for speculative execution side channel mitigations. Note: For 5-level paging, Guest physical address width can be configured, with parameter "phys-bits". Unless explicitly specified, we still use its default value, even for Icelake-Server cpu model. At present, hold on expose IA32_ARCH_CAPABILITIES to guest, as 1) This MSR actually presents more than 1 'feature', maintainers are considering expanding current features presentation of only CPUIDs to MSR bits; 2) a reasonable default value for MSR_IA32_ARCH_CAPABILITIES needs to settled first. These 2 are actully beyond Icelake CPU model itself but fundamental. So split these work apart and do it later. https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg00774.html https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg00796.html Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1530781798-183214-6-git-send-email-robert.hu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-18 02:16:21 +0000