2019-06-04 08:11:32 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-11-23 14:30:32 +00:00
|
|
|
/*
|
|
|
|
* Kernel-based Virtual Machine driver for Linux
|
|
|
|
* cpuid support routines
|
|
|
|
*
|
|
|
|
* derived from arch/x86/kvm/x86.c
|
|
|
|
*
|
|
|
|
* Copyright 2011 Red Hat, Inc. and/or its affiliates.
|
|
|
|
* Copyright IBM Corporation, 2008
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kvm_host.h>
|
2016-07-14 00:19:00 +00:00
|
|
|
#include <linux/export.h>
|
2011-12-14 16:58:18 +00:00
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/uaccess.h>
|
2017-02-05 11:07:04 +00:00
|
|
|
#include <linux/sched/stat.h>
|
|
|
|
|
2016-11-07 06:03:20 +00:00
|
|
|
#include <asm/processor.h>
|
2011-11-23 14:30:32 +00:00
|
|
|
#include <asm/user.h>
|
2015-04-28 06:41:33 +00:00
|
|
|
#include <asm/fpu/xstate.h>
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
#include <asm/sgx.h>
|
2022-02-24 16:56:10 +00:00
|
|
|
#include <asm/cpuid.h>
|
2011-11-23 14:30:32 +00:00
|
|
|
#include "cpuid.h"
|
|
|
|
#include "lapic.h"
|
|
|
|
#include "mmu.h"
|
|
|
|
#include "trace.h"
|
2015-06-19 11:54:23 +00:00
|
|
|
#include "pmu.h"
|
2011-11-23 14:30:32 +00:00
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
/*
|
|
|
|
* Unlike "struct cpuinfo_x86.x86_capability", kvm_cpu_caps doesn't need to be
|
|
|
|
* aligned to sizeof(unsigned long) because it's not accessed via bitops.
|
|
|
|
*/
|
2021-04-12 04:21:35 +00:00
|
|
|
u32 kvm_cpu_caps[NR_KVM_CPU_CAPS] __read_mostly;
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_cpu_caps);
|
|
|
|
|
2022-01-05 12:35:29 +00:00
|
|
|
u32 xstate_required_size(u64 xstate_bv, bool compacted)
|
2013-10-02 14:06:16 +00:00
|
|
|
{
|
|
|
|
int feature_bit = 0;
|
|
|
|
u32 ret = XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET;
|
|
|
|
|
2015-09-02 23:31:26 +00:00
|
|
|
xstate_bv &= XFEATURE_MASK_EXTEND;
|
2013-10-02 14:06:16 +00:00
|
|
|
while (xstate_bv) {
|
|
|
|
if (xstate_bv & 0x1) {
|
2014-12-03 13:38:01 +00:00
|
|
|
u32 eax, ebx, ecx, edx, offset;
|
2013-10-02 14:06:16 +00:00
|
|
|
cpuid_count(0xD, feature_bit, &eax, &ebx, &ecx, &edx);
|
2022-01-05 12:35:14 +00:00
|
|
|
/* ECX[1]: 64B alignment in compacted form */
|
|
|
|
if (compacted)
|
|
|
|
offset = (ecx & 0x2) ? ALIGN(ret, 64) : ret;
|
|
|
|
else
|
|
|
|
offset = ebx;
|
2014-12-03 13:38:01 +00:00
|
|
|
ret = max(ret, offset + eax);
|
2013-10-02 14:06:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
xstate_bv >>= 1;
|
|
|
|
feature_bit++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-09-24 01:15:28 +00:00
|
|
|
/*
|
|
|
|
* This one is tied to SSB in the user API, and not
|
|
|
|
* visible in /proc/cpuinfo.
|
|
|
|
*/
|
2022-08-30 22:52:09 +00:00
|
|
|
#define KVM_X86_FEATURE_AMD_PSFD (13*32+28) /* Predictive Store Forwarding Disable */
|
2021-09-24 01:15:28 +00:00
|
|
|
|
2019-12-17 21:32:42 +00:00
|
|
|
#define F feature_bit
|
2022-11-25 12:58:38 +00:00
|
|
|
|
|
|
|
/* Scattered Flag - For features that are scattered by cpufeatures.h. */
|
|
|
|
#define SF(name) \
|
|
|
|
({ \
|
|
|
|
BUILD_BUG_ON(X86_FEATURE_##name >= MAX_CPU_FEATURES); \
|
|
|
|
(boot_cpu_has(X86_FEATURE_##name) ? F(name) : 0); \
|
|
|
|
})
|
2014-12-03 13:34:47 +00:00
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
/*
|
|
|
|
* Magic value used by KVM when querying userspace-provided CPUID entries and
|
|
|
|
* doesn't care about the CPIUD index because the index of the function in
|
|
|
|
* question is not significant. Note, this magic value must have at least one
|
|
|
|
* bit set in bits[63:32] and must be consumed as a u64 by cpuid_entry2_find()
|
|
|
|
* to avoid false positives when processing guest CPUID input.
|
|
|
|
*/
|
|
|
|
#define KVM_CPUID_INDEX_NOT_SIGNIFICANT -1ull
|
2021-09-24 01:15:28 +00:00
|
|
|
|
2020-10-01 13:05:39 +00:00
|
|
|
static inline struct kvm_cpuid_entry2 *cpuid_entry2_find(
|
2022-07-12 00:06:45 +00:00
|
|
|
struct kvm_cpuid_entry2 *entries, int nent, u32 function, u64 index)
|
2020-10-01 13:05:39 +00:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *e;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nent; i++) {
|
|
|
|
e = &entries[i];
|
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
if (e->function != function)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the index isn't significant, use the first entry with a
|
|
|
|
* matching function. It's userspace's responsibilty to not
|
|
|
|
* provide "duplicate" entries in all cases.
|
|
|
|
*/
|
|
|
|
if (!(e->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX) || e->index == index)
|
|
|
|
return e;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Similarly, use the first matching entry if KVM is doing a
|
|
|
|
* lookup (as opposed to emulating CPUID) for a function that's
|
|
|
|
* architecturally defined as not having a significant index.
|
|
|
|
*/
|
|
|
|
if (index == KVM_CPUID_INDEX_NOT_SIGNIFICANT) {
|
|
|
|
/*
|
|
|
|
* Direct lookups from KVM should not diverge from what
|
|
|
|
* KVM defines internally (the architectural behavior).
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(cpuid_function_is_indexed(function));
|
2020-10-01 13:05:39 +00:00
|
|
|
return e;
|
2022-07-12 00:06:45 +00:00
|
|
|
}
|
2020-10-01 13:05:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
static int kvm_check_cpuid(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid_entry2 *entries,
|
|
|
|
int nent)
|
2020-07-09 04:34:22 +00:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
2022-01-05 12:35:19 +00:00
|
|
|
u64 xfeatures;
|
2020-07-09 04:34:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The existing code assumes virtual address is 48-bit or 57-bit in the
|
|
|
|
* canonical address checks; exit if it is ever changed.
|
|
|
|
*/
|
2022-07-12 00:06:45 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 0x80000008,
|
|
|
|
KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
2020-07-09 04:34:22 +00:00
|
|
|
if (best) {
|
|
|
|
int vaddr_bits = (best->eax & 0xff00) >> 8;
|
|
|
|
|
|
|
|
if (vaddr_bits != 48 && vaddr_bits != 57 && vaddr_bits != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
/*
|
|
|
|
* Exposing dynamic xfeatures to the guest requires additional
|
|
|
|
* enabling in the FPU, e.g. to expand the guest XSAVE state size.
|
|
|
|
*/
|
|
|
|
best = cpuid_entry2_find(entries, nent, 0xd, 0);
|
|
|
|
if (!best)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
xfeatures = best->eax | ((u64)best->edx << 32);
|
|
|
|
xfeatures &= XFEATURE_MASK_USER_DYNAMIC;
|
|
|
|
if (!xfeatures)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return fpu_enable_guest_xfd_features(&vcpu->arch.guest_fpu, xfeatures);
|
2020-07-09 04:34:22 +00:00
|
|
|
}
|
|
|
|
|
2022-01-17 15:05:40 +00:00
|
|
|
/* Check whether the supplied CPUID data is equal to what is already set for the vCPU. */
|
|
|
|
static int kvm_cpuid_check_equal(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
|
|
|
|
int nent)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *orig;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (nent != vcpu->arch.cpuid_nent)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
for (i = 0; i < nent; i++) {
|
|
|
|
orig = &vcpu->arch.cpuid_entries[i];
|
|
|
|
if (e2[i].function != orig->function ||
|
|
|
|
e2[i].index != orig->index ||
|
2022-01-26 13:18:04 +00:00
|
|
|
e2[i].flags != orig->flags ||
|
2022-01-17 15:05:40 +00:00
|
|
|
e2[i].eax != orig->eax || e2[i].ebx != orig->ebx ||
|
|
|
|
e2[i].ecx != orig->ecx || e2[i].edx != orig->edx)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-11-05 09:51:01 +00:00
|
|
|
static void kvm_update_kvm_cpuid_base(struct kvm_vcpu *vcpu)
|
2020-10-27 23:10:42 +00:00
|
|
|
{
|
2021-11-05 09:51:01 +00:00
|
|
|
u32 function;
|
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
|
|
|
vcpu->arch.kvm_cpuid_base = 0;
|
|
|
|
|
|
|
|
for_each_possible_hypervisor_cpuid_base(function) {
|
2022-07-12 00:06:45 +00:00
|
|
|
entry = kvm_find_cpuid_entry(vcpu, function);
|
2021-11-05 09:51:01 +00:00
|
|
|
|
|
|
|
if (entry) {
|
|
|
|
u32 signature[3];
|
|
|
|
|
|
|
|
signature[0] = entry->ebx;
|
|
|
|
signature[1] = entry->ecx;
|
|
|
|
signature[2] = entry->edx;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(signature) > sizeof(KVM_SIGNATURE));
|
|
|
|
if (!memcmp(signature, KVM_SIGNATURE, sizeof(signature))) {
|
|
|
|
vcpu->arch.kvm_cpuid_base = function;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
static struct kvm_cpuid_entry2 *__kvm_find_kvm_cpuid_features(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid_entry2 *entries, int nent)
|
2021-11-05 09:51:01 +00:00
|
|
|
{
|
|
|
|
u32 base = vcpu->arch.kvm_cpuid_base;
|
|
|
|
|
|
|
|
if (!base)
|
|
|
|
return NULL;
|
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
return cpuid_entry2_find(entries, nent, base | KVM_CPUID_FEATURES,
|
|
|
|
KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
2022-01-17 15:05:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct kvm_cpuid_entry2 *kvm_find_kvm_cpuid_features(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return __kvm_find_kvm_cpuid_features(vcpu, vcpu->arch.cpuid_entries,
|
|
|
|
vcpu->arch.cpuid_nent);
|
2021-11-05 09:51:01 +00:00
|
|
|
}
|
2020-10-27 23:10:42 +00:00
|
|
|
|
2021-11-05 09:51:01 +00:00
|
|
|
void kvm_update_pv_runtime(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best = kvm_find_kvm_cpuid_features(vcpu);
|
2020-10-27 23:10:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* save the feature bitmap to avoid cpuid lookup for every PV
|
|
|
|
* operation
|
|
|
|
*/
|
|
|
|
if (best)
|
|
|
|
vcpu->arch.pv_cpuid.features = best->eax;
|
|
|
|
}
|
|
|
|
|
2022-01-24 10:36:05 +00:00
|
|
|
/*
|
|
|
|
* Calculate guest's supported XCR0 taking into account guest CPUID data and
|
2022-05-24 13:56:23 +00:00
|
|
|
* KVM's supported XCR0 (comprised of host's XCR0 and KVM_SUPPORTED_XCR0).
|
2022-01-24 10:36:05 +00:00
|
|
|
*/
|
|
|
|
static u64 cpuid_get_supported_xcr0(struct kvm_cpuid_entry2 *entries, int nent)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
|
|
|
best = cpuid_entry2_find(entries, nent, 0xd, 0);
|
|
|
|
if (!best)
|
|
|
|
return 0;
|
|
|
|
|
2022-05-24 13:56:23 +00:00
|
|
|
return (best->eax | ((u64)best->edx << 32)) & kvm_caps.supported_xcr0;
|
2022-01-24 10:36:05 +00:00
|
|
|
}
|
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
static void __kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *entries,
|
|
|
|
int nent)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
2022-01-24 10:36:05 +00:00
|
|
|
u64 guest_supported_xcr0 = cpuid_get_supported_xcr0(entries, nent);
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 1, KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
2020-07-08 06:50:48 +00:00
|
|
|
if (best) {
|
|
|
|
/* Update OSXSAVE bit */
|
|
|
|
if (boot_cpu_has(X86_FEATURE_XSAVE))
|
|
|
|
cpuid_entry_change(best, X86_FEATURE_OSXSAVE,
|
2020-03-02 23:56:31 +00:00
|
|
|
kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE));
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2020-07-08 06:50:48 +00:00
|
|
|
cpuid_entry_change(best, X86_FEATURE_APIC,
|
2020-03-02 23:56:31 +00:00
|
|
|
vcpu->arch.apic_base & MSR_IA32_APICBASE_ENABLE);
|
2020-07-08 06:50:48 +00:00
|
|
|
}
|
2016-11-09 17:50:11 +00:00
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 7, 0);
|
2020-03-02 23:56:31 +00:00
|
|
|
if (best && boot_cpu_has(X86_FEATURE_PKU) && best->function == 0x7)
|
|
|
|
cpuid_entry_change(best, X86_FEATURE_OSPKE,
|
|
|
|
kvm_read_cr4_bits(vcpu, X86_CR4_PKE));
|
2016-03-22 08:51:21 +00:00
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 0xD, 0);
|
2020-07-09 04:34:23 +00:00
|
|
|
if (best)
|
2020-04-29 15:43:12 +00:00
|
|
|
best->ebx = xstate_required_size(vcpu->arch.xcr0, false);
|
2013-10-02 14:06:15 +00:00
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 0xD, 1);
|
2020-03-02 23:56:30 +00:00
|
|
|
if (best && (cpuid_entry_has(best, X86_FEATURE_XSAVES) ||
|
|
|
|
cpuid_entry_has(best, X86_FEATURE_XSAVEC)))
|
2014-12-03 13:38:01 +00:00
|
|
|
best->ebx = xstate_required_size(vcpu->arch.xcr0, true);
|
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
best = __kvm_find_kvm_cpuid_features(vcpu, entries, nent);
|
2018-03-12 11:53:03 +00:00
|
|
|
if (kvm_hlt_in_guest(vcpu->kvm) && best &&
|
|
|
|
(best->eax & (1 << KVM_FEATURE_PV_UNHALT)))
|
|
|
|
best->eax &= ~(1 << KVM_FEATURE_PV_UNHALT);
|
|
|
|
|
2019-05-21 06:06:54 +00:00
|
|
|
if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT)) {
|
2022-07-12 00:06:45 +00:00
|
|
|
best = cpuid_entry2_find(entries, nent, 0x1, KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
2020-03-02 23:56:31 +00:00
|
|
|
if (best)
|
|
|
|
cpuid_entry_change(best, X86_FEATURE_MWAIT,
|
|
|
|
vcpu->arch.ia32_misc_enable_msr &
|
|
|
|
MSR_IA32_MISC_ENABLE_MWAIT);
|
2019-05-21 06:06:54 +00:00
|
|
|
}
|
2022-01-24 10:36:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Bits 127:0 of the allowed SECS.ATTRIBUTES (CPUID.0x12.0x1) enumerate
|
|
|
|
* the supported XSAVE Feature Request Mask (XFRM), i.e. the enclave's
|
|
|
|
* requested XCR0 value. The enclave's XFRM must be a subset of XCRO
|
|
|
|
* at the time of EENTER, thus adjust the allowed XFRM by the guest's
|
|
|
|
* supported XCR0. Similar to XCR0 handling, FP and SSE are forced to
|
|
|
|
* '1' even on CPUs that don't support XSAVE.
|
|
|
|
*/
|
|
|
|
best = cpuid_entry2_find(entries, nent, 0x12, 0x1);
|
|
|
|
if (best) {
|
|
|
|
best->ecx &= guest_supported_xcr0 & 0xffffffff;
|
|
|
|
best->edx &= guest_supported_xcr0 >> 32;
|
|
|
|
best->ecx |= XFEATURE_MASK_FPSSE;
|
|
|
|
}
|
2020-07-09 04:34:23 +00:00
|
|
|
}
|
2022-01-17 15:05:39 +00:00
|
|
|
|
|
|
|
void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
__kvm_update_cpuid_runtime(vcpu, vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent);
|
|
|
|
}
|
2020-10-29 17:06:48 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_update_cpuid_runtime);
|
2020-07-09 04:34:23 +00:00
|
|
|
|
2022-08-30 13:37:09 +00:00
|
|
|
static bool kvm_cpuid_has_hyperv(struct kvm_cpuid_entry2 *entries, int nent)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
|
|
|
entry = cpuid_entry2_find(entries, nent, HYPERV_CPUID_INTERFACE,
|
|
|
|
KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
|
|
|
return entry && entry->eax == HYPERV_CPUID_SIGNATURE_EAX;
|
|
|
|
}
|
|
|
|
|
2020-07-09 04:34:24 +00:00
|
|
|
static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
|
2020-07-09 04:34:23 +00:00
|
|
|
{
|
|
|
|
struct kvm_lapic *apic = vcpu->arch.apic;
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 1);
|
2020-07-09 04:34:23 +00:00
|
|
|
if (best && apic) {
|
|
|
|
if (cpuid_entry_has(best, X86_FEATURE_TSC_DEADLINE_TIMER))
|
|
|
|
apic->lapic_timer.timer_mode_mask = 3 << 17;
|
|
|
|
else
|
|
|
|
apic->lapic_timer.timer_mode_mask = 1 << 17;
|
|
|
|
|
|
|
|
kvm_apic_set_version(vcpu);
|
|
|
|
}
|
|
|
|
|
2022-08-24 03:30:55 +00:00
|
|
|
vcpu->arch.guest_supported_xcr0 =
|
2022-01-24 10:36:05 +00:00
|
|
|
cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent);
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
|
2022-08-24 03:30:56 +00:00
|
|
|
/*
|
|
|
|
* FP+SSE can always be saved/restored via KVM_{G,S}ET_XSAVE, even if
|
|
|
|
* XSAVE/XCRO are not exposed to the guest, and even if XSAVE isn't
|
|
|
|
* supported by the host.
|
|
|
|
*/
|
|
|
|
vcpu->arch.guest_fpu.fpstate->user_xfeatures = vcpu->arch.guest_supported_xcr0 |
|
|
|
|
XFEATURE_MASK_FPSSE;
|
x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0
During host/guest switch (like in kvm_arch_vcpu_ioctl_run()), the kernel
swaps the fpu between host/guest contexts, by using fpu_swap_kvm_fpstate().
When xsave feature is available, the fpu swap is done by:
- xsave(s) instruction, with guest's fpstate->xfeatures as mask, is used
to store the current state of the fpu registers to a buffer.
- xrstor(s) instruction, with (fpu_kernel_cfg.max_features &
XFEATURE_MASK_FPSTATE) as mask, is used to put the buffer into fpu regs.
For xsave(s) the mask is used to limit what parts of the fpu regs will
be copied to the buffer. Likewise on xrstor(s), the mask is used to
limit what parts of the fpu regs will be changed.
The mask for xsave(s), the guest's fpstate->xfeatures, is defined on
kvm_arch_vcpu_create(), which (in summary) sets it to all features
supported by the cpu which are enabled on kernel config.
This means that xsave(s) will save to guest buffer all the fpu regs
contents the cpu has enabled when the guest is paused, even if they
are not used.
This would not be an issue, if xrstor(s) would also do that.
xrstor(s)'s mask for host/guest swap is basically every valid feature
contained in kernel config, except XFEATURE_MASK_PKRU.
Accordingto kernel src, it is instead switched in switch_to() and
flush_thread().
Then, the following happens with a host supporting PKRU starts a
guest that does not support it:
1 - Host has XFEATURE_MASK_PKRU set. 1st switch to guest,
2 - xsave(s) fpu regs to host fpustate (buffer has XFEATURE_MASK_PKRU)
3 - xrstor(s) guest fpustate to fpu regs (fpu regs have XFEATURE_MASK_PKRU)
4 - guest runs, then switch back to host,
5 - xsave(s) fpu regs to guest fpstate (buffer now have XFEATURE_MASK_PKRU)
6 - xrstor(s) host fpstate to fpu regs.
7 - kvm_vcpu_ioctl_x86_get_xsave() copy guest fpstate to userspace (with
XFEATURE_MASK_PKRU, which should not be supported by guest vcpu)
On 5, even though the guest does not support PKRU, it does have the flag
set on guest fpstate, which is transferred to userspace via vcpu ioctl
KVM_GET_XSAVE.
This becomes a problem when the user decides on migrating the above guest
to another machine that does not support PKRU: the new host restores
guest's fpu regs to as they were before (xrstor(s)), but since the new
host don't support PKRU, a general-protection exception ocurs in xrstor(s)
and that crashes the guest.
This can be solved by making the guest's fpstate->user_xfeatures hold
a copy of guest_supported_xcr0. This way, on 7 the only flags copied to
userspace will be the ones compatible to guest requirements, and thus
there will be no issue during migration.
As a bonus, it will also fail if userspace tries to set fpu features
(with the KVM_SET_XSAVE ioctl) that are not compatible to the guest
configuration. Such features will never be returned by KVM_GET_XSAVE
or KVM_GET_XSAVE2.
Also, since kvm_vcpu_after_set_cpuid() now sets fpstate->user_xfeatures,
there is not need to set it in kvm_check_cpuid(). So, change
fpstate_realloc() so it does not touch fpstate->user_xfeatures if a
non-NULL guest_fpu is passed, which is the case when kvm_check_cpuid()
calls it.
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Message-Id: <20220217053028.96432-2-leobras@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-17 05:30:29 +00:00
|
|
|
|
2020-10-27 23:10:42 +00:00
|
|
|
kvm_update_pv_runtime(vcpu);
|
|
|
|
|
2015-03-29 20:56:12 +00:00
|
|
|
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
|
2021-02-04 00:01:15 +00:00
|
|
|
vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu);
|
2015-03-29 20:56:12 +00:00
|
|
|
|
2015-06-19 11:44:45 +00:00
|
|
|
kvm_pmu_refresh(vcpu);
|
2020-07-08 00:39:55 +00:00
|
|
|
vcpu->arch.cr4_guest_rsvd_bits =
|
|
|
|
__cr4_reserved_bits(guest_cpuid_has, vcpu);
|
2020-09-30 04:16:56 +00:00
|
|
|
|
2022-08-30 13:37:09 +00:00
|
|
|
kvm_hv_set_cpuid(vcpu, kvm_cpuid_has_hyperv(vcpu->arch.cpuid_entries,
|
|
|
|
vcpu->arch.cpuid_nent));
|
2021-01-26 13:48:14 +00:00
|
|
|
|
2020-09-30 04:16:56 +00:00
|
|
|
/* Invoke the vendor callback only after the above state is updated. */
|
2021-01-15 03:27:56 +00:00
|
|
|
static_call(kvm_x86_vcpu_after_set_cpuid)(vcpu);
|
KVM: x86: Use reserved_gpa_bits to calculate reserved PxE bits
Use reserved_gpa_bits, which accounts for exceptions to the maxphyaddr
rule, e.g. SEV's C-bit, for the page {table,directory,etc...} entry (PxE)
reserved bits checks. For SEV, the C-bit is ignored by hardware when
walking pages tables, e.g. the APM states:
Note that while the guest may choose to set the C-bit explicitly on
instruction pages and page table addresses, the value of this bit is a
don't-care in such situations as hardware always performs these as
private accesses.
Such behavior is expected to hold true for other features that repurpose
GPA bits, e.g. KVM could theoretically emulate SME or MKTME, which both
allow non-zero repurposed bits in the page tables. Conceptually, KVM
should apply reserved GPA checks universally, and any features that do
not adhere to the basic rule should be explicitly handled, i.e. if a GPA
bit is repurposed but not allowed in page tables for whatever reason.
Refactor __reset_rsvds_bits_mask() to take the pre-generated reserved
bits mask, and opportunistically clean up its code, e.g. to align lines
and comments.
Practically speaking, this is change is a likely a glorified nop given
the current KVM code base. SEV's C-bit is the only repurposed GPA bit,
and KVM doesn't support shadowing encrypted page tables (which is
theoretically possible via SEV debug APIs).
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210204000117.3303214-9-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-04 00:01:13 +00:00
|
|
|
|
|
|
|
/*
|
KVM: x86: Force all MMUs to reinitialize if guest CPUID is modified
Invalidate all MMUs' roles after a CPUID update to force reinitizliation
of the MMU context/helpers. Despite the efforts of commit de3ccd26fafc
("KVM: MMU: record maximum physical address width in kvm_mmu_extended_role"),
there are still a handful of CPUID-based properties that affect MMU
behavior but are not incorporated into mmu_role. E.g. 1gb hugepage
support, AMD vs. Intel handling of bit 8, and SEV's C-Bit location all
factor into the guest's reserved PTE bits.
The obvious alternative would be to add all such properties to mmu_role,
but doing so provides no benefit over simply forcing a reinitialization
on every CPUID update, as setting guest CPUID is a rare operation.
Note, reinitializing all MMUs after a CPUID update does not fix all of
KVM's woes. Specifically, kvm_mmu_page_role doesn't track the CPUID
properties, which means that a vCPU can reuse shadow pages that should
not exist for the new vCPU model, e.g. that map GPAs that are now illegal
(due to MAXPHYADDR changes) or that set bits that are now reserved
(PAGE_SIZE for 1gb pages), etc...
Tracking the relevant CPUID properties in kvm_mmu_page_role would address
the majority of problems, but fully tracking that much state in the
shadow page role comes with an unpalatable cost as it would require a
non-trivial increase in KVM's memory footprint. The GBPAGES case is even
worse, as neither Intel nor AMD provides a way to disable 1gb hugepage
support in the hardware page walker, i.e. it's a virtualization hole that
can't be closed when using TDP.
In other words, resetting the MMU after a CPUID update is largely a
superficial fix. But, it will allow reverting the tracking of MAXPHYADDR
in the mmu_role, and that case in particular needs to mostly work because
KVM's shadow_root_level depends on guest MAXPHYADDR when 5-level paging
is supported. For cases where KVM botches guest behavior, the damage is
limited to that guest. But for the shadow_root_level, a misconfigured
MMU can cause KVM to incorrectly access memory, e.g. due to walking off
the end of its shadow page tables.
Fixes: 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed")
Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210622175739.3610207-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-22 17:56:51 +00:00
|
|
|
* Except for the MMU, which needs to do its thing any vendor specific
|
|
|
|
* adjustments to the reserved GPA bits.
|
KVM: x86: Use reserved_gpa_bits to calculate reserved PxE bits
Use reserved_gpa_bits, which accounts for exceptions to the maxphyaddr
rule, e.g. SEV's C-bit, for the page {table,directory,etc...} entry (PxE)
reserved bits checks. For SEV, the C-bit is ignored by hardware when
walking pages tables, e.g. the APM states:
Note that while the guest may choose to set the C-bit explicitly on
instruction pages and page table addresses, the value of this bit is a
don't-care in such situations as hardware always performs these as
private accesses.
Such behavior is expected to hold true for other features that repurpose
GPA bits, e.g. KVM could theoretically emulate SME or MKTME, which both
allow non-zero repurposed bits in the page tables. Conceptually, KVM
should apply reserved GPA checks universally, and any features that do
not adhere to the basic rule should be explicitly handled, i.e. if a GPA
bit is repurposed but not allowed in page tables for whatever reason.
Refactor __reset_rsvds_bits_mask() to take the pre-generated reserved
bits mask, and opportunistically clean up its code, e.g. to align lines
and comments.
Practically speaking, this is change is a likely a glorified nop given
the current KVM code base. SEV's C-bit is the only repurposed GPA bit,
and KVM doesn't support shadowing encrypted page tables (which is
theoretically possible via SEV debug APIs).
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210204000117.3303214-9-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-04 00:01:13 +00:00
|
|
|
*/
|
KVM: x86: Force all MMUs to reinitialize if guest CPUID is modified
Invalidate all MMUs' roles after a CPUID update to force reinitizliation
of the MMU context/helpers. Despite the efforts of commit de3ccd26fafc
("KVM: MMU: record maximum physical address width in kvm_mmu_extended_role"),
there are still a handful of CPUID-based properties that affect MMU
behavior but are not incorporated into mmu_role. E.g. 1gb hugepage
support, AMD vs. Intel handling of bit 8, and SEV's C-Bit location all
factor into the guest's reserved PTE bits.
The obvious alternative would be to add all such properties to mmu_role,
but doing so provides no benefit over simply forcing a reinitialization
on every CPUID update, as setting guest CPUID is a rare operation.
Note, reinitializing all MMUs after a CPUID update does not fix all of
KVM's woes. Specifically, kvm_mmu_page_role doesn't track the CPUID
properties, which means that a vCPU can reuse shadow pages that should
not exist for the new vCPU model, e.g. that map GPAs that are now illegal
(due to MAXPHYADDR changes) or that set bits that are now reserved
(PAGE_SIZE for 1gb pages), etc...
Tracking the relevant CPUID properties in kvm_mmu_page_role would address
the majority of problems, but fully tracking that much state in the
shadow page role comes with an unpalatable cost as it would require a
non-trivial increase in KVM's memory footprint. The GBPAGES case is even
worse, as neither Intel nor AMD provides a way to disable 1gb hugepage
support in the hardware page walker, i.e. it's a virtualization hole that
can't be closed when using TDP.
In other words, resetting the MMU after a CPUID update is largely a
superficial fix. But, it will allow reverting the tracking of MAXPHYADDR
in the mmu_role, and that case in particular needs to mostly work because
KVM's shadow_root_level depends on guest MAXPHYADDR when 5-level paging
is supported. For cases where KVM botches guest behavior, the damage is
limited to that guest. But for the shadow_root_level, a misconfigured
MMU can cause KVM to incorrectly access memory, e.g. due to walking off
the end of its shadow page tables.
Fixes: 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed")
Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210622175739.3610207-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-22 17:56:51 +00:00
|
|
|
kvm_mmu_after_set_cpuid(vcpu);
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
|
2015-03-29 20:56:12 +00:00
|
|
|
int cpuid_query_maxphyaddr(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000000);
|
2015-03-29 20:56:12 +00:00
|
|
|
if (!best || best->eax < 0x80000008)
|
|
|
|
goto not_found;
|
2022-07-12 00:06:45 +00:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000008);
|
2015-03-29 20:56:12 +00:00
|
|
|
if (best)
|
|
|
|
return best->eax & 0xff;
|
|
|
|
not_found:
|
|
|
|
return 36;
|
|
|
|
}
|
|
|
|
|
2021-02-04 00:01:15 +00:00
|
|
|
/*
|
|
|
|
* This "raw" version returns the reserved GPA bits without any adjustments for
|
|
|
|
* encryption technologies that usurp bits. The raw mask should be used if and
|
|
|
|
* only if hardware does _not_ strip the usurped bits, e.g. in virtual MTRRs.
|
|
|
|
*/
|
|
|
|
u64 kvm_vcpu_reserved_gpa_bits_raw(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return rsvd_bits(cpuid_maxphyaddr(vcpu), 63);
|
|
|
|
}
|
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
|
|
|
|
int nent)
|
|
|
|
{
|
2022-01-05 12:35:19 +00:00
|
|
|
int r;
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2022-01-17 15:05:39 +00:00
|
|
|
__kvm_update_cpuid_runtime(vcpu, e2, nent);
|
|
|
|
|
2022-01-17 15:05:40 +00:00
|
|
|
/*
|
|
|
|
* KVM does not correctly handle changing guest CPUID after KVM_RUN, as
|
|
|
|
* MAXPHYADDR, GBPAGES support, AMD reserved bit behavior, etc.. aren't
|
|
|
|
* tracked in kvm_mmu_page_role. As a result, KVM may miss guest page
|
|
|
|
* faults due to reusing SPs/SPTEs. In practice no sane VMM mucks with
|
|
|
|
* the core vCPU model on the fly. It would've been better to forbid any
|
|
|
|
* KVM_SET_CPUID{,2} calls after KVM_RUN altogether but unfortunately
|
|
|
|
* some VMMs (e.g. QEMU) reuse vCPU fds for CPU hotplug/unplug and do
|
|
|
|
* KVM_SET_CPUID{,2} again. To support this legacy behavior, check
|
|
|
|
* whether the supplied CPUID data is equal to what's already set.
|
|
|
|
*/
|
2022-01-25 21:04:45 +00:00
|
|
|
if (vcpu->arch.last_vmentry_cpu != -1) {
|
|
|
|
r = kvm_cpuid_check_equal(vcpu, e2, nent);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
kvfree(e2);
|
|
|
|
return 0;
|
|
|
|
}
|
2022-01-17 15:05:40 +00:00
|
|
|
|
2022-08-30 13:37:09 +00:00
|
|
|
if (kvm_cpuid_has_hyperv(e2, nent)) {
|
|
|
|
r = kvm_hv_vcpu_init(vcpu);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
r = kvm_check_cpuid(vcpu, e2, nent);
|
|
|
|
if (r)
|
|
|
|
return r;
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
kvfree(vcpu->arch.cpuid_entries);
|
|
|
|
vcpu->arch.cpuid_entries = e2;
|
|
|
|
vcpu->arch.cpuid_nent = nent;
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
kvm_update_kvm_cpuid_base(vcpu);
|
|
|
|
kvm_vcpu_after_set_cpuid(vcpu);
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2022-01-05 12:35:19 +00:00
|
|
|
return 0;
|
2021-11-05 09:51:00 +00:00
|
|
|
}
|
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
/* when an old userspace process fills a new kernel module */
|
|
|
|
int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid *cpuid,
|
|
|
|
struct kvm_cpuid_entry __user *entries)
|
|
|
|
{
|
|
|
|
int r, i;
|
2020-10-01 13:05:40 +00:00
|
|
|
struct kvm_cpuid_entry *e = NULL;
|
|
|
|
struct kvm_cpuid_entry2 *e2 = NULL;
|
2011-11-23 14:30:32 +00:00
|
|
|
|
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
2020-10-01 13:05:40 +00:00
|
|
|
return -E2BIG;
|
|
|
|
|
2016-06-01 12:09:19 +00:00
|
|
|
if (cpuid->nent) {
|
2020-10-01 13:05:40 +00:00
|
|
|
e = vmemdup_user(entries, array_size(sizeof(*e), cpuid->nent));
|
|
|
|
if (IS_ERR(e))
|
|
|
|
return PTR_ERR(e);
|
|
|
|
|
|
|
|
e2 = kvmalloc_array(cpuid->nent, sizeof(*e2), GFP_KERNEL_ACCOUNT);
|
|
|
|
if (!e2) {
|
|
|
|
r = -ENOMEM;
|
|
|
|
goto out_free_cpuid;
|
2020-06-03 10:11:31 +00:00
|
|
|
}
|
2016-06-01 12:09:19 +00:00
|
|
|
}
|
2011-11-23 14:30:32 +00:00
|
|
|
for (i = 0; i < cpuid->nent; i++) {
|
2020-10-01 13:05:40 +00:00
|
|
|
e2[i].function = e[i].function;
|
|
|
|
e2[i].eax = e[i].eax;
|
|
|
|
e2[i].ebx = e[i].ebx;
|
|
|
|
e2[i].ecx = e[i].ecx;
|
|
|
|
e2[i].edx = e[i].edx;
|
|
|
|
e2[i].index = 0;
|
|
|
|
e2[i].flags = 0;
|
|
|
|
e2[i].padding[0] = 0;
|
|
|
|
e2[i].padding[1] = 0;
|
|
|
|
e2[i].padding[2] = 0;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
2020-10-01 13:05:40 +00:00
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
r = kvm_set_cpuid(vcpu, e2, cpuid->nent);
|
|
|
|
if (r)
|
2020-10-01 13:05:40 +00:00
|
|
|
kvfree(e2);
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2020-10-01 13:05:40 +00:00
|
|
|
out_free_cpuid:
|
|
|
|
kvfree(e);
|
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid2 *cpuid,
|
|
|
|
struct kvm_cpuid_entry2 __user *entries)
|
|
|
|
{
|
2020-10-01 13:05:40 +00:00
|
|
|
struct kvm_cpuid_entry2 *e2 = NULL;
|
2011-11-23 14:30:32 +00:00
|
|
|
int r;
|
|
|
|
|
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
2020-10-01 13:05:40 +00:00
|
|
|
return -E2BIG;
|
|
|
|
|
|
|
|
if (cpuid->nent) {
|
|
|
|
e2 = vmemdup_user(entries, array_size(sizeof(*e2), cpuid->nent));
|
|
|
|
if (IS_ERR(e2))
|
|
|
|
return PTR_ERR(e2);
|
|
|
|
}
|
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
r = kvm_set_cpuid(vcpu, e2, cpuid->nent);
|
|
|
|
if (r)
|
2020-10-01 13:05:40 +00:00
|
|
|
kvfree(e2);
|
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
return r;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_vcpu_ioctl_get_cpuid2(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid2 *cpuid,
|
|
|
|
struct kvm_cpuid_entry2 __user *entries)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
r = -E2BIG;
|
|
|
|
if (cpuid->nent < vcpu->arch.cpuid_nent)
|
|
|
|
goto out;
|
|
|
|
r = -EFAULT;
|
2021-01-28 02:44:51 +00:00
|
|
|
if (copy_to_user(entries, vcpu->arch.cpuid_entries,
|
2011-11-23 14:30:32 +00:00
|
|
|
vcpu->arch.cpuid_nent * sizeof(struct kvm_cpuid_entry2)))
|
|
|
|
goto out;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
cpuid->nent = vcpu->arch.cpuid_nent;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2021-04-12 04:21:35 +00:00
|
|
|
/* Mask kvm_cpu_caps for @leaf with the raw CPUID capabilities of this CPU. */
|
2021-04-21 01:08:50 +00:00
|
|
|
static __always_inline void __kvm_cpu_cap_mask(unsigned int leaf)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
{
|
2020-03-02 23:56:52 +00:00
|
|
|
const struct cpuid_reg cpuid = x86_feature_cpuid(leaf * 32);
|
|
|
|
struct kvm_cpuid_entry2 entry;
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
reverse_cpuid_check(leaf);
|
2020-03-02 23:56:52 +00:00
|
|
|
|
|
|
|
cpuid_count(cpuid.function, cpuid.index,
|
|
|
|
&entry.eax, &entry.ebx, &entry.ecx, &entry.edx);
|
|
|
|
|
2020-03-25 19:12:59 +00:00
|
|
|
kvm_cpu_caps[leaf] &= *__cpuid_entry_get_reg(&entry, cpuid.reg);
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
}
|
|
|
|
|
2021-04-21 01:08:50 +00:00
|
|
|
static __always_inline
|
2022-11-25 12:58:39 +00:00
|
|
|
void kvm_cpu_cap_init_kvm_defined(enum kvm_only_cpuid_leafs leaf, u32 mask)
|
2021-04-12 04:21:35 +00:00
|
|
|
{
|
2022-11-25 12:58:39 +00:00
|
|
|
/* Use kvm_cpu_cap_mask for leafs that aren't KVM-only. */
|
2021-04-12 04:21:35 +00:00
|
|
|
BUILD_BUG_ON(leaf < NCAPINTS);
|
|
|
|
|
|
|
|
kvm_cpu_caps[leaf] = mask;
|
|
|
|
|
|
|
|
__kvm_cpu_cap_mask(leaf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void kvm_cpu_cap_mask(enum cpuid_leafs leaf, u32 mask)
|
|
|
|
{
|
2022-11-25 12:58:39 +00:00
|
|
|
/* Use kvm_cpu_cap_init_kvm_defined for KVM-only leafs. */
|
2021-04-12 04:21:35 +00:00
|
|
|
BUILD_BUG_ON(leaf >= NCAPINTS);
|
|
|
|
|
|
|
|
kvm_cpu_caps[leaf] &= mask;
|
|
|
|
|
|
|
|
__kvm_cpu_cap_mask(leaf);
|
|
|
|
}
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
void kvm_set_cpu_caps(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
unsigned int f_gbpages = F(GBPAGES);
|
|
|
|
unsigned int f_lm = F(LM);
|
2022-01-05 12:35:27 +00:00
|
|
|
unsigned int f_xfd = F(XFD);
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
#else
|
|
|
|
unsigned int f_gbpages = 0;
|
|
|
|
unsigned int f_lm = 0;
|
2022-01-05 12:35:27 +00:00
|
|
|
unsigned int f_xfd = 0;
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
#endif
|
2021-04-12 04:21:35 +00:00
|
|
|
memset(kvm_cpu_caps, 0, sizeof(kvm_cpu_caps));
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
|
2021-04-12 04:21:35 +00:00
|
|
|
BUILD_BUG_ON(sizeof(kvm_cpu_caps) - (NKVMCAPINTS * sizeof(*kvm_cpu_caps)) >
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
sizeof(boot_cpu_data.x86_capability));
|
|
|
|
|
|
|
|
memcpy(&kvm_cpu_caps, &boot_cpu_data.x86_capability,
|
2021-04-12 04:21:35 +00:00
|
|
|
sizeof(kvm_cpu_caps) - (NKVMCAPINTS * sizeof(*kvm_cpu_caps)));
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_1_ECX,
|
|
|
|
/*
|
|
|
|
* NOTE: MONITOR (and MWAIT) are emulated as NOP, but *not*
|
|
|
|
* advertised to guests via CPUID!
|
|
|
|
*/
|
|
|
|
F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ |
|
|
|
|
0 /* DS-CPL, VMX, SMX, EST */ |
|
|
|
|
0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* Reserved */ |
|
2020-05-29 07:43:45 +00:00
|
|
|
F(FMA) | F(CX16) | 0 /* xTPR Update */ | F(PDCM) |
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
F(PCID) | 0 /* Reserved, DCA */ | F(XMM4_1) |
|
|
|
|
F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) |
|
|
|
|
0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE */ | F(AVX) |
|
|
|
|
F(F16C) | F(RDRAND)
|
|
|
|
);
|
2020-03-02 23:56:54 +00:00
|
|
|
/* KVM emulates x2apic in software irrespective of host support. */
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_X2APIC);
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_1_EDX,
|
|
|
|
F(FPU) | F(VME) | F(DE) | F(PSE) |
|
|
|
|
F(TSC) | F(MSR) | F(PAE) | F(MCE) |
|
|
|
|
F(CX8) | F(APIC) | 0 /* Reserved */ | F(SEP) |
|
|
|
|
F(MTRR) | F(PGE) | F(MCA) | F(CMOV) |
|
|
|
|
F(PAT) | F(PSE36) | 0 /* PSN */ | F(CLFLUSH) |
|
|
|
|
0 /* Reserved, DS, ACPI */ | F(MMX) |
|
|
|
|
F(FXSR) | F(XMM) | F(XMM2) | F(SELFSNOOP) |
|
|
|
|
0 /* HTT, TM, Reserved, PBE */
|
|
|
|
);
|
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_7_0_EBX,
|
2022-02-04 00:13:48 +00:00
|
|
|
F(FSGSBASE) | F(SGX) | F(BMI1) | F(HLE) | F(AVX2) |
|
|
|
|
F(FDP_EXCPTN_ONLY) | F(SMEP) | F(BMI2) | F(ERMS) | F(INVPCID) |
|
|
|
|
F(RTM) | F(ZERO_FCS_FDS) | 0 /*MPX*/ | F(AVX512F) |
|
|
|
|
F(AVX512DQ) | F(RDSEED) | F(ADX) | F(SMAP) | F(AVX512IFMA) |
|
|
|
|
F(CLFLUSHOPT) | F(CLWB) | 0 /*INTEL_PT*/ | F(AVX512PF) |
|
|
|
|
F(AVX512ER) | F(AVX512CD) | F(SHA_NI) | F(AVX512BW) |
|
|
|
|
F(AVX512VL));
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_7_ECX,
|
2020-05-12 23:59:16 +00:00
|
|
|
F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(RDPID) |
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) |
|
|
|
|
F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) |
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/ |
|
2021-05-06 10:30:04 +00:00
|
|
|
F(SGX_LC) | F(BUS_LOCK_DETECT)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
/* Set LA57 based on hardware capability. */
|
|
|
|
if (cpuid_ecx(7) & F(LA57))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_LA57);
|
|
|
|
|
2020-05-12 23:59:16 +00:00
|
|
|
/*
|
|
|
|
* PKU not yet implemented for shadow paging and requires OSPKE
|
|
|
|
* to be set on the host. Clear it if that is not the case
|
|
|
|
*/
|
|
|
|
if (!tdp_enabled || !boot_cpu_has(X86_FEATURE_OSPKE))
|
|
|
|
kvm_cpu_cap_clear(X86_FEATURE_PKU);
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_7_EDX,
|
|
|
|
F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
|
|
|
|
F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) |
|
2020-08-09 17:04:56 +00:00
|
|
|
F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) |
|
2022-01-05 12:35:27 +00:00
|
|
|
F(SERIALIZE) | F(TSXLDTRK) | F(AVX512_FP16) |
|
|
|
|
F(AMX_TILE) | F(AMX_INT8) | F(AMX_BF16)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
2020-03-02 23:56:54 +00:00
|
|
|
/* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software. */
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_TSC_ADJUST);
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_ARCH_CAPABILITIES);
|
|
|
|
|
|
|
|
if (boot_cpu_has(X86_FEATURE_IBPB) && boot_cpu_has(X86_FEATURE_IBRS))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL);
|
|
|
|
if (boot_cpu_has(X86_FEATURE_STIBP))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP);
|
|
|
|
if (boot_cpu_has(X86_FEATURE_AMD_SSBD))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD);
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_7_1_EAX,
|
2022-11-25 12:58:42 +00:00
|
|
|
F(AVX_VNNI) | F(AVX512_BF16) | F(CMPCCXADD) | F(AMX_FP16) |
|
|
|
|
F(AVX_IFMA)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
2022-11-25 12:58:43 +00:00
|
|
|
kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX,
|
2022-11-25 12:58:45 +00:00
|
|
|
F(AVX_VNNI_INT8) | F(AVX_NE_CONVERT) | F(PREFETCHITI)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_D_1_EAX,
|
2022-01-05 12:35:27 +00:00
|
|
|
F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES) | f_xfd
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
2022-11-25 12:58:39 +00:00
|
|
|
kvm_cpu_cap_init_kvm_defined(CPUID_12_EAX,
|
KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest
The new Asynchronous Exit (AEX) notification mechanism (AEX-notify)
allows one enclave to receive a notification in the ERESUME after the
enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function
(ENCLU[EDECCSSA]) to facilitate the AEX notification handling. The new
EDECCSSA is enumerated via CPUID(EAX=0x12,ECX=0x0):EAX[11].
Besides Allowing reporting the new AEX-notify attribute to KVM guests,
also allow reporting the new EDECCSSA user leaf function to KVM guests
so the guest can fully utilize the AEX-notify mechanism.
Similar to existing X86_FEATURE_SGX1 and X86_FEATURE_SGX2, introduce a
new scattered X86_FEATURE_SGX_EDECCSSA bit for the new EDECCSSA, and
report it in KVM's supported CPUIDs.
Note, no additional KVM enabling is required to allow the guest to use
EDECCSSA. It's impossible to trap ENCLU (without completely preventing
the guest from using SGX). Advertise EDECCSSA as supported purely so
that userspace doesn't need to special case EDECCSSA, i.e. doesn't need
to manually check host CPUID.
The inability to trap ENCLU also means that KVM can't prevent the guest
from using EDECCSSA, but that virtualization hole is benign as far as
KVM is concerned. EDECCSSA is simply a fancy way to modify internal
enclave state.
More background about how do AEX-notify and EDECCSSA work:
SGX maintains a Current State Save Area Frame (CSSA) for each enclave
thread. When AEX happens, the enclave thread context is saved to the
CSSA and the CSSA is increased by 1. For a normal ERESUME which doesn't
deliver AEX notification, it restores the saved thread context from the
previously saved SSA and decreases the CSSA. If AEX-notify is enabled
for one enclave, the ERESUME acts differently. Instead of restoring the
saved thread context and decreasing the CSSA, it acts like EENTER which
doesn't decrease the CSSA but establishes a clean slate thread context
using the CSSA for the enclave to handle the notification. After some
handling, the enclave must discard the "new-established" SSA and switch
back to the previously saved SSA (upon AEX). Otherwise, the enclave
will run out of SSA space upon further AEXs and eventually fail to run.
To solve this problem, the new EDECCSSA essentially decreases the CSSA.
It can be used by the enclave notification handler to switch back to the
previous saved SSA when needed, i.e. after it handles the notification.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Sean Christopherson <seanjc@google.com>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/all/20221101022422.858944-1-kai.huang%40intel.com
2022-11-01 02:24:22 +00:00
|
|
|
SF(SGX1) | SF(SGX2) | SF(SGX_EDECCSSA)
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
);
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_8000_0001_ECX,
|
|
|
|
F(LAHF_LM) | F(CMP_LEGACY) | 0 /*SVM*/ | 0 /* ExtApicSpace */ |
|
|
|
|
F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
|
|
|
|
F(3DNOWPREFETCH) | F(OSVW) | 0 /* IBS */ | F(XOP) |
|
|
|
|
0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM) |
|
2021-11-17 08:03:04 +00:00
|
|
|
F(TOPOEXT) | 0 /* PERFCTR_CORE */
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_8000_0001_EDX,
|
|
|
|
F(FPU) | F(VME) | F(DE) | F(PSE) |
|
|
|
|
F(TSC) | F(MSR) | F(PAE) | F(MCE) |
|
|
|
|
F(CX8) | F(APIC) | 0 /* Reserved */ | F(SYSCALL) |
|
|
|
|
F(MTRR) | F(PGE) | F(MCA) | F(CMOV) |
|
|
|
|
F(PAT) | F(PSE36) | 0 /* Reserved */ |
|
KVM: x86: Allow guest to set EFER.NX=1 on non-PAE 32-bit kernels
Remove an ancient restriction that disallowed exposing EFER.NX to the
guest if EFER.NX=0 on the host, even if NX is fully supported by the CPU.
The motivation of the check, added by commit 2cc51560aed0 ("KVM: VMX:
Avoid saving and restoring msr_efer on lightweight vmexit"), was to rule
out the case of host.EFER.NX=0 and guest.EFER.NX=1 so that KVM could run
the guest with the host's EFER.NX and thus avoid context switching EFER
if the only divergence was the NX bit.
Fast forward to today, and KVM has long since stopped running the guest
with the host's EFER.NX. Not only does KVM context switch EFER if
host.EFER.NX=1 && guest.EFER.NX=0, KVM also forces host.EFER.NX=0 &&
guest.EFER.NX=1 when using shadow paging (to emulate SMEP). Furthermore,
the entire motivation for the restriction was made obsolete over a decade
ago when Intel added dedicated host and guest EFER fields in the VMCS
(Nehalem timeframe), which reduced the overhead of context switching EFER
from 400+ cycles (2 * WRMSR + 1 * RDMSR) to a mere ~2 cycles.
In practice, the removed restriction only affects non-PAE 32-bit kernels,
as EFER.NX is set during boot if NX is supported and the kernel will use
PAE paging (32-bit or 64-bit), regardless of whether or not the kernel
will actually use NX itself (mark PTEs non-executable).
Alternatively and/or complementarily, startup_32_smp() in head_32.S could
be modified to set EFER.NX=1 regardless of paging mode, thus eliminating
the scenario where NX is supported but not enabled. However, that runs
the risk of breaking non-KVM non-PAE kernels (though the risk is very,
very low as there are no known EFER.NX errata), and also eliminates an
easy-to-use mechanism for stressing KVM's handling of guest vs. host EFER
across nested virtualization transitions.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210805183804.1221554-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-08-05 18:38:04 +00:00
|
|
|
F(NX) | 0 /* Reserved */ | F(MMXEXT) | F(MMX) |
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
F(FXSR) | F(FXSR_OPT) | f_gbpages | F(RDTSCP) |
|
|
|
|
0 /* Reserved */ | f_lm | F(3DNOWEXT) | F(3DNOW)
|
|
|
|
);
|
|
|
|
|
|
|
|
if (!tdp_enabled && IS_ENABLED(CONFIG_X86_64))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_GBPAGES);
|
|
|
|
|
|
|
|
kvm_cpu_cap_mask(CPUID_8000_0008_EBX,
|
|
|
|
F(CLZERO) | F(XSAVEERPTR) |
|
|
|
|
F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) | F(VIRT_SSBD) |
|
2021-09-24 01:15:28 +00:00
|
|
|
F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_ON) |
|
2022-08-30 22:52:09 +00:00
|
|
|
__feature_bit(KVM_X86_FEATURE_AMD_PSFD)
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
);
|
|
|
|
|
2020-03-02 23:56:54 +00:00
|
|
|
/*
|
|
|
|
* AMD has separate bits for each SPEC_CTRL bit.
|
|
|
|
* arch/x86/kernel/cpu/bugs.c is kind enough to
|
|
|
|
* record that in cpufeatures so use them.
|
|
|
|
*/
|
|
|
|
if (boot_cpu_has(X86_FEATURE_IBPB))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB);
|
|
|
|
if (boot_cpu_has(X86_FEATURE_IBRS))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_IBRS);
|
|
|
|
if (boot_cpu_has(X86_FEATURE_STIBP))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_STIBP);
|
|
|
|
if (boot_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_SSBD);
|
|
|
|
if (!boot_cpu_has_bug(X86_BUG_SPEC_STORE_BYPASS))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_SSB_NO);
|
|
|
|
/*
|
|
|
|
* The preference is to use SPEC CTRL MSR instead of the
|
|
|
|
* VIRT_SPEC MSR.
|
|
|
|
*/
|
|
|
|
if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) &&
|
|
|
|
!boot_cpu_has(X86_FEATURE_AMD_SSBD))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD);
|
|
|
|
|
2020-03-02 23:56:42 +00:00
|
|
|
/*
|
|
|
|
* Hide all SVM features by default, SVM will set the cap bits for
|
|
|
|
* features it emulates and/or exposes for L1.
|
|
|
|
*/
|
|
|
|
kvm_cpu_cap_mask(CPUID_8000_000A_EDX, 0);
|
|
|
|
|
2021-04-22 02:11:15 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_8000_001F_EAX,
|
|
|
|
0 /* SME */ | F(SEV) | 0 /* VM_PAGE_FLUSH */ | F(SEV_ES) |
|
|
|
|
F(SME_COHERENT));
|
|
|
|
|
2023-01-24 16:33:13 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_8000_0021_EAX,
|
2023-01-24 16:33:15 +00:00
|
|
|
F(NO_NESTED_DATA_BP) | F(LFENCE_RDTSC) | 0 /* SmmPgCfgLock */ |
|
2023-01-24 16:33:13 +00:00
|
|
|
BIT(6) /* NULL_SEL_CLR_BASE */ | 0 /* PrefetchCtlMsr */
|
|
|
|
);
|
2023-01-24 16:33:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Synthesize "LFENCE is serializing" into the AMD-defined entry in
|
|
|
|
* KVM's supported CPUID if the feature is reported as supported by the
|
|
|
|
* kernel. LFENCE_RDTSC was a Linux-defined synthetic feature long
|
|
|
|
* before AMD joined the bandwagon, e.g. LFENCE is serializing on most
|
|
|
|
* CPUs that support SSE2. On CPUs that don't support AMD's leaf,
|
|
|
|
* kvm_cpu_cap_mask() will unfortunately drop the flag due to ANDing
|
|
|
|
* the mask with the raw host CPUID, and reporting support in AMD's
|
|
|
|
* leaf can make it easier for userspace to detect the feature.
|
|
|
|
*/
|
2023-01-24 16:33:13 +00:00
|
|
|
if (cpu_feature_enabled(X86_FEATURE_LFENCE_RDTSC))
|
2023-01-24 16:33:15 +00:00
|
|
|
kvm_cpu_cap_set(X86_FEATURE_LFENCE_RDTSC);
|
2023-01-24 16:33:13 +00:00
|
|
|
if (!static_cpu_has_bug(X86_BUG_NULL_SEG))
|
|
|
|
kvm_cpu_caps[CPUID_8000_0021_EAX] |= BIT(6) /* NULL_SEL_CLR_BASE */;
|
|
|
|
kvm_cpu_caps[CPUID_8000_0021_EAX] |= BIT(9) /* NO_SMM_CTL_MSR */;
|
|
|
|
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
kvm_cpu_cap_mask(CPUID_C000_0001_EDX,
|
|
|
|
F(XSTORE) | F(XSTORE_EN) | F(XCRYPT) | F(XCRYPT_EN) |
|
|
|
|
F(ACE2) | F(ACE2_EN) | F(PHE) | F(PHE_EN) |
|
|
|
|
F(PMM) | F(PMM_EN)
|
|
|
|
);
|
2021-05-04 17:17:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Hide RDTSCP and RDPID if either feature is reported as supported but
|
|
|
|
* probing MSR_TSC_AUX failed. This is purely a sanity check and
|
|
|
|
* should never happen, but the guest will likely crash if RDTSCP or
|
|
|
|
* RDPID is misreported, and KVM has botched MSR_TSC_AUX emulation in
|
|
|
|
* the past. For example, the sanity check may fire if this instance of
|
|
|
|
* KVM is running as L1 on top of an older, broken KVM.
|
|
|
|
*/
|
|
|
|
if (WARN_ON((kvm_cpu_cap_has(X86_FEATURE_RDTSCP) ||
|
|
|
|
kvm_cpu_cap_has(X86_FEATURE_RDPID)) &&
|
|
|
|
!kvm_is_supported_user_return_msr(MSR_TSC_AUX))) {
|
|
|
|
kvm_cpu_cap_clear(X86_FEATURE_RDTSCP);
|
|
|
|
kvm_cpu_cap_clear(X86_FEATURE_RDPID);
|
|
|
|
}
|
KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking
Calculate the CPUID masks for KVM_GET_SUPPORTED_CPUID at load time using
what is effectively a KVM-adjusted copy of boot_cpu_data, or more
precisely, the x86_capability array in boot_cpu_data.
In terms of KVM support, the vast majority of CPUID feature bits are
constant, and *all* feature support is known at KVM load time. Rather
than apply boot_cpu_data, which is effectively read-only after init,
at runtime, copy it into a KVM-specific array and use *that* to mask
CPUID registers.
In additional to consolidating the masking, kvm_cpu_caps can be adjusted
by SVM/VMX at load time and thus eliminate all feature bit manipulation
in ->set_supported_cpuid().
Opportunistically clean up a few warts:
- Replace bare "unsigned" with "unsigned int" when a feature flag is
captured in a local variable, e.g. f_nx.
- Sort the CPUID masks by function, index and register (alphabetically
for registers, i.e. EBX comes before ECX/EDX).
- Remove the superfluous /* cpuid 7.0.ecx */ comments.
No functional change intended.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Call kvm_set_cpu_caps from kvm_x86_ops->hardware_setup due to fixed
GBPAGES patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:41 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_set_cpu_caps);
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
struct kvm_cpuid_array {
|
|
|
|
struct kvm_cpuid_entry2 *entries;
|
2020-06-04 04:16:36 +00:00
|
|
|
int maxnent;
|
2020-03-02 23:56:19 +00:00
|
|
|
int nent;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct kvm_cpuid_entry2 *do_host_cpuid(struct kvm_cpuid_array *array,
|
2020-03-02 23:56:16 +00:00
|
|
|
u32 function, u32 index)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
2020-03-02 23:56:19 +00:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
|
|
|
if (array->nent >= array->maxnent)
|
2020-03-02 23:56:16 +00:00
|
|
|
return NULL;
|
2020-03-02 23:56:19 +00:00
|
|
|
|
|
|
|
entry = &array->entries[array->nent++];
|
2020-03-02 23:56:16 +00:00
|
|
|
|
2021-10-28 17:15:55 +00:00
|
|
|
memset(entry, 0, sizeof(*entry));
|
2011-11-23 14:30:32 +00:00
|
|
|
entry->function = function;
|
|
|
|
entry->index = index;
|
2021-10-28 17:15:55 +00:00
|
|
|
switch (function & 0xC0000000) {
|
|
|
|
case 0x40000000:
|
|
|
|
/* Hypervisor leaves are always synthesized by __do_cpuid_func. */
|
|
|
|
return entry;
|
|
|
|
|
2021-10-21 21:19:27 +00:00
|
|
|
case 0x80000000:
|
|
|
|
/*
|
|
|
|
* 0x80000021 is sometimes synthesized by __do_cpuid_func, which
|
|
|
|
* would result in out-of-bounds calls to do_host_cpuid.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
static int max_cpuid_80000000;
|
|
|
|
if (!READ_ONCE(max_cpuid_80000000))
|
|
|
|
WRITE_ONCE(max_cpuid_80000000, cpuid_eax(0x80000000));
|
|
|
|
if (function > READ_ONCE(max_cpuid_80000000))
|
|
|
|
return entry;
|
|
|
|
}
|
2022-03-22 15:29:06 +00:00
|
|
|
break;
|
2021-10-21 21:19:27 +00:00
|
|
|
|
2021-10-28 17:15:55 +00:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2019-06-24 08:23:33 +00:00
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
cpuid_count(entry->function, entry->index,
|
|
|
|
&entry->eax, &entry->ebx, &entry->ecx, &entry->edx);
|
2019-07-04 10:20:48 +00:00
|
|
|
|
2022-02-24 16:56:10 +00:00
|
|
|
if (cpuid_function_is_indexed(function))
|
2019-07-04 10:20:48 +00:00
|
|
|
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
|
2020-03-02 23:56:16 +00:00
|
|
|
|
|
|
|
return entry;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
static int __do_cpuid_func_emulated(struct kvm_cpuid_array *array, u32 func)
|
2013-09-22 14:44:50 +00:00
|
|
|
{
|
2020-03-02 23:56:56 +00:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
|
|
|
if (array->nent >= array->maxnent)
|
|
|
|
return -E2BIG;
|
2020-03-02 23:56:19 +00:00
|
|
|
|
2020-03-02 23:56:56 +00:00
|
|
|
entry = &array->entries[array->nent];
|
2019-06-24 08:23:33 +00:00
|
|
|
entry->function = func;
|
|
|
|
entry->index = 0;
|
|
|
|
entry->flags = 0;
|
|
|
|
|
2013-10-29 11:54:56 +00:00
|
|
|
switch (func) {
|
|
|
|
case 0:
|
2016-07-12 09:04:26 +00:00
|
|
|
entry->eax = 7;
|
2020-03-02 23:56:19 +00:00
|
|
|
++array->nent;
|
2013-10-29 11:54:56 +00:00
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
entry->ecx = F(MOVBE);
|
2020-03-02 23:56:19 +00:00
|
|
|
++array->nent;
|
2013-10-29 11:54:56 +00:00
|
|
|
break;
|
2016-07-12 09:04:26 +00:00
|
|
|
case 7:
|
|
|
|
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
|
2019-06-24 08:23:33 +00:00
|
|
|
entry->eax = 0;
|
2021-05-04 17:17:21 +00:00
|
|
|
if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP))
|
|
|
|
entry->ecx = F(RDPID);
|
2020-03-02 23:56:19 +00:00
|
|
|
++array->nent;
|
2021-05-28 20:07:56 +00:00
|
|
|
break;
|
2013-10-29 11:54:56 +00:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-09-22 14:44:50 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
2020-03-02 23:56:19 +00:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2020-03-02 23:56:17 +00:00
|
|
|
int r, i, max_idx;
|
2011-11-23 14:30:32 +00:00
|
|
|
|
|
|
|
/* all calls to cpuid_count() should be made on the same cpu */
|
|
|
|
get_cpu();
|
2011-11-28 09:20:29 +00:00
|
|
|
|
|
|
|
r = -E2BIG;
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
entry = do_host_cpuid(array, function, 0);
|
2020-03-02 23:56:56 +00:00
|
|
|
if (!entry)
|
2011-11-28 09:20:29 +00:00
|
|
|
goto out;
|
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
switch (function) {
|
|
|
|
case 0:
|
2019-06-06 01:18:45 +00:00
|
|
|
/* Limited to the highest leaf implemented in KVM. */
|
|
|
|
entry->eax = min(entry->eax, 0x1fU);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
|
|
|
case 1:
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_1_EDX);
|
|
|
|
cpuid_entry_override(entry, CPUID_1_ECX);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
2020-03-02 23:56:17 +00:00
|
|
|
case 2:
|
KVM: x86: Squash CPUID 0x2.0 insanity for modern CPUs
Rework CPUID 0x2.0 to be a normal CPUID leaf if it returns "01" in AL,
i.e. EAX & 0xff, as a step towards removing KVM's stateful CPUID code
altogether.
Long ago, Intel documented CPUID 0x2.0 as being a stateful leaf, e.g. a
version of the SDM circa 1995 states:
The least-significant byte in register EAX (register AL) indicates the
number of times the CPUID instruction must be executed with an input
value of 2 to get a complete description of the processors's caches
and TLBs. The Pentium Pro family of processors will return a 1.
A 2000 version of the SDM only updated the paragraph to reference
Intel's new processory family:
The first member of the family of Pentium 4 processors will return a 1.
Fast forward to the present, and Intel's SDM now states:
The least-significant byte in register EAX (register AL) will always
return 01H. Software should ignore this value and not interpret it as
an information descriptor.
AMD's APM simply states that CPUID 0x2 is reserved.
Given that CPUID itself was introduced in the Pentium, odds are good
that the only Intel CPU family that *maybe* implemented a stateful CPUID
was the P5. Which obviously did not support VMX, or KVM.
In other words, KVM's emulation of a stateful CPUID 0x2.0 has likely
been dead code from the day it was introduced. This is backed up by
commit 0fdf8e59faa5c ("KVM: Fix cpuid iteration on multiple leaves per
eac"), which shows that the stateful iteration code was completely
broken when it was introduced by commit 0771671749b59 ("KVM: Enhance
guest cpuid management"), i.e. not actually tested.
Annotate all stateful code paths as "unlikely", but defer its removal to
a future patch to simplify reinstating the code if by some miracle there
is someone running KVM on a CPU with a stateful CPUID 0x2.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:50 +00:00
|
|
|
/*
|
|
|
|
* On ancient CPUs, function 2 entries are STATEFUL. That is,
|
|
|
|
* CPUID(function=2, index=0) may return different results each
|
|
|
|
* time, with the least-significant byte in EAX enumerating the
|
|
|
|
* number of times software should do CPUID(2, 0).
|
|
|
|
*
|
2020-03-02 23:56:51 +00:00
|
|
|
* Modern CPUs, i.e. every CPU KVM has *ever* run on are less
|
|
|
|
* idiotic. Intel's SDM states that EAX & 0xff "will always
|
|
|
|
* return 01H. Software should ignore this value and not
|
KVM: x86: Squash CPUID 0x2.0 insanity for modern CPUs
Rework CPUID 0x2.0 to be a normal CPUID leaf if it returns "01" in AL,
i.e. EAX & 0xff, as a step towards removing KVM's stateful CPUID code
altogether.
Long ago, Intel documented CPUID 0x2.0 as being a stateful leaf, e.g. a
version of the SDM circa 1995 states:
The least-significant byte in register EAX (register AL) indicates the
number of times the CPUID instruction must be executed with an input
value of 2 to get a complete description of the processors's caches
and TLBs. The Pentium Pro family of processors will return a 1.
A 2000 version of the SDM only updated the paragraph to reference
Intel's new processory family:
The first member of the family of Pentium 4 processors will return a 1.
Fast forward to the present, and Intel's SDM now states:
The least-significant byte in register EAX (register AL) will always
return 01H. Software should ignore this value and not interpret it as
an information descriptor.
AMD's APM simply states that CPUID 0x2 is reserved.
Given that CPUID itself was introduced in the Pentium, odds are good
that the only Intel CPU family that *maybe* implemented a stateful CPUID
was the P5. Which obviously did not support VMX, or KVM.
In other words, KVM's emulation of a stateful CPUID 0x2.0 has likely
been dead code from the day it was introduced. This is backed up by
commit 0fdf8e59faa5c ("KVM: Fix cpuid iteration on multiple leaves per
eac"), which shows that the stateful iteration code was completely
broken when it was introduced by commit 0771671749b59 ("KVM: Enhance
guest cpuid management"), i.e. not actually tested.
Annotate all stateful code paths as "unlikely", but defer its removal to
a future patch to simplify reinstating the code if by some miracle there
is someone running KVM on a CPU with a stateful CPUID 0x2.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:50 +00:00
|
|
|
* interpret it as an informational descriptor", while AMD's
|
|
|
|
* APM states that CPUID(2) is reserved.
|
2020-03-02 23:56:51 +00:00
|
|
|
*
|
|
|
|
* WARN if a frankenstein CPU that supports virtualization and
|
|
|
|
* a stateful CPUID.0x2 is encountered.
|
KVM: x86: Squash CPUID 0x2.0 insanity for modern CPUs
Rework CPUID 0x2.0 to be a normal CPUID leaf if it returns "01" in AL,
i.e. EAX & 0xff, as a step towards removing KVM's stateful CPUID code
altogether.
Long ago, Intel documented CPUID 0x2.0 as being a stateful leaf, e.g. a
version of the SDM circa 1995 states:
The least-significant byte in register EAX (register AL) indicates the
number of times the CPUID instruction must be executed with an input
value of 2 to get a complete description of the processors's caches
and TLBs. The Pentium Pro family of processors will return a 1.
A 2000 version of the SDM only updated the paragraph to reference
Intel's new processory family:
The first member of the family of Pentium 4 processors will return a 1.
Fast forward to the present, and Intel's SDM now states:
The least-significant byte in register EAX (register AL) will always
return 01H. Software should ignore this value and not interpret it as
an information descriptor.
AMD's APM simply states that CPUID 0x2 is reserved.
Given that CPUID itself was introduced in the Pentium, odds are good
that the only Intel CPU family that *maybe* implemented a stateful CPUID
was the P5. Which obviously did not support VMX, or KVM.
In other words, KVM's emulation of a stateful CPUID 0x2.0 has likely
been dead code from the day it was introduced. This is backed up by
commit 0fdf8e59faa5c ("KVM: Fix cpuid iteration on multiple leaves per
eac"), which shows that the stateful iteration code was completely
broken when it was introduced by commit 0771671749b59 ("KVM: Enhance
guest cpuid management"), i.e. not actually tested.
Annotate all stateful code paths as "unlikely", but defer its removal to
a future patch to simplify reinstating the code if by some miracle there
is someone running KVM on a CPU with a stateful CPUID 0x2.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-02 23:56:50 +00:00
|
|
|
*/
|
2020-03-02 23:56:51 +00:00
|
|
|
WARN_ON_ONCE((entry->eax & 0xff) > 1);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
2019-03-27 20:15:36 +00:00
|
|
|
/* functions 4 and 0x8000001d have additional index. */
|
|
|
|
case 4:
|
2020-03-02 23:56:18 +00:00
|
|
|
case 0x8000001d:
|
|
|
|
/*
|
|
|
|
* Read entries until the cache type in the previous entry is
|
|
|
|
* zero, i.e. indicates an invalid entry.
|
|
|
|
*/
|
2020-03-02 23:56:19 +00:00
|
|
|
for (i = 1; entry->eax & 0x1f; ++i) {
|
|
|
|
entry = do_host_cpuid(array, function, i);
|
|
|
|
if (!entry)
|
2020-03-02 23:56:08 +00:00
|
|
|
goto out;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
break;
|
2015-05-24 15:22:38 +00:00
|
|
|
case 6: /* Thermal management */
|
|
|
|
entry->eax = 0x4; /* allow ARAT */
|
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = 0;
|
|
|
|
break;
|
2019-07-04 10:18:13 +00:00
|
|
|
/* function 7 has additional index. */
|
2020-03-02 23:56:17 +00:00
|
|
|
case 7:
|
2020-03-02 23:56:48 +00:00
|
|
|
entry->eax = min(entry->eax, 1u);
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_7_0_EBX);
|
|
|
|
cpuid_entry_override(entry, CPUID_7_ECX);
|
|
|
|
cpuid_entry_override(entry, CPUID_7_EDX);
|
2020-03-02 23:56:48 +00:00
|
|
|
|
2020-03-02 23:56:49 +00:00
|
|
|
/* KVM only supports 0x7.0 and 0x7.1, capped above via min(). */
|
|
|
|
if (entry->eax == 1) {
|
|
|
|
entry = do_host_cpuid(array, function, 1);
|
2020-03-02 23:56:19 +00:00
|
|
|
if (!entry)
|
2019-07-04 10:18:13 +00:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_7_1_EAX);
|
2022-11-25 12:58:43 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_7_1_EDX);
|
2020-03-02 23:56:48 +00:00
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
2019-07-04 10:18:13 +00:00
|
|
|
}
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
2011-11-10 12:57:28 +00:00
|
|
|
case 0xa: { /* Architectural Performance Monitoring */
|
|
|
|
union cpuid10_eax eax;
|
|
|
|
union cpuid10_edx edx;
|
|
|
|
|
2022-04-27 11:31:49 +00:00
|
|
|
if (!static_cpu_has(X86_FEATURE_ARCH_PERFMON)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2022-04-11 10:19:44 +00:00
|
|
|
eax.split.version_id = kvm_pmu_cap.version;
|
|
|
|
eax.split.num_counters = kvm_pmu_cap.num_counters_gp;
|
|
|
|
eax.split.bit_width = kvm_pmu_cap.bit_width_gp;
|
|
|
|
eax.split.mask_length = kvm_pmu_cap.events_mask_len;
|
|
|
|
edx.split.num_counters_fixed = kvm_pmu_cap.num_counters_fixed;
|
|
|
|
edx.split.bit_width_fixed = kvm_pmu_cap.bit_width_fixed;
|
2011-11-10 12:57:28 +00:00
|
|
|
|
2022-04-11 10:19:44 +00:00
|
|
|
if (kvm_pmu_cap.version)
|
2021-06-28 07:43:54 +00:00
|
|
|
edx.split.anythread_deprecated = 1;
|
2020-10-28 19:42:47 +00:00
|
|
|
edx.split.reserved1 = 0;
|
|
|
|
edx.split.reserved2 = 0;
|
2011-11-10 12:57:28 +00:00
|
|
|
|
|
|
|
entry->eax = eax.full;
|
2022-04-11 10:19:44 +00:00
|
|
|
entry->ebx = kvm_pmu_cap.events_mask;
|
2011-11-10 12:57:28 +00:00
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = edx.full;
|
|
|
|
break;
|
|
|
|
}
|
2019-06-06 01:18:45 +00:00
|
|
|
/*
|
|
|
|
* Per Intel's SDM, the 0x1f is a superset of 0xb,
|
|
|
|
* thus they can be handled by common code.
|
|
|
|
*/
|
|
|
|
case 0x1f:
|
2020-03-02 23:56:17 +00:00
|
|
|
case 0xb:
|
2019-09-25 18:17:14 +00:00
|
|
|
/*
|
2020-03-02 23:56:19 +00:00
|
|
|
* Populate entries until the level type (ECX[15:8]) of the
|
|
|
|
* previous entry is zero. Note, CPUID EAX.{0x1f,0xb}.0 is
|
|
|
|
* the starting entry, filled by the primary do_host_cpuid().
|
2019-09-25 18:17:14 +00:00
|
|
|
*/
|
2020-03-02 23:56:19 +00:00
|
|
|
for (i = 1; entry->ecx & 0xff00; ++i) {
|
|
|
|
entry = do_host_cpuid(array, function, i);
|
|
|
|
if (!entry)
|
2011-11-28 09:20:29 +00:00
|
|
|
goto out;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
break;
|
2022-01-05 12:35:15 +00:00
|
|
|
case 0xd: {
|
2022-05-24 13:56:23 +00:00
|
|
|
u64 permitted_xcr0 = kvm_caps.supported_xcr0 & xstate_get_guest_group_perm();
|
|
|
|
u64 permitted_xss = kvm_caps.supported_xss;
|
2022-01-05 12:35:15 +00:00
|
|
|
|
2022-01-25 11:52:23 +00:00
|
|
|
entry->eax &= permitted_xcr0;
|
|
|
|
entry->ebx = xstate_required_size(permitted_xcr0, false);
|
2014-12-04 17:30:41 +00:00
|
|
|
entry->ecx = entry->ebx;
|
2022-01-25 11:52:23 +00:00
|
|
|
entry->edx &= permitted_xcr0 >> 32;
|
|
|
|
if (!permitted_xcr0)
|
2014-11-21 17:13:26 +00:00
|
|
|
break;
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
entry = do_host_cpuid(array, function, 1);
|
|
|
|
if (!entry)
|
2020-03-02 23:56:09 +00:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_D_1_EAX);
|
2020-03-02 23:56:19 +00:00
|
|
|
if (entry->eax & (F(XSAVES)|F(XSAVEC)))
|
2022-01-25 11:52:23 +00:00
|
|
|
entry->ebx = xstate_required_size(permitted_xcr0 | permitted_xss,
|
2020-03-05 15:11:56 +00:00
|
|
|
true);
|
|
|
|
else {
|
2022-01-25 11:52:23 +00:00
|
|
|
WARN_ON_ONCE(permitted_xss != 0);
|
2020-03-02 23:56:19 +00:00
|
|
|
entry->ebx = 0;
|
2020-03-05 15:11:56 +00:00
|
|
|
}
|
2022-01-25 11:52:23 +00:00
|
|
|
entry->ecx &= permitted_xss;
|
|
|
|
entry->edx &= permitted_xss >> 32;
|
2020-03-02 23:56:09 +00:00
|
|
|
|
2020-03-02 23:56:21 +00:00
|
|
|
for (i = 2; i < 64; ++i) {
|
2020-03-05 15:11:56 +00:00
|
|
|
bool s_state;
|
2022-01-25 11:52:23 +00:00
|
|
|
if (permitted_xcr0 & BIT_ULL(i))
|
2020-03-05 15:11:56 +00:00
|
|
|
s_state = false;
|
2022-01-25 11:52:23 +00:00
|
|
|
else if (permitted_xss & BIT_ULL(i))
|
2020-03-05 15:11:56 +00:00
|
|
|
s_state = true;
|
|
|
|
else
|
2020-03-02 23:56:10 +00:00
|
|
|
continue;
|
2020-03-02 23:56:09 +00:00
|
|
|
|
2020-03-02 23:56:21 +00:00
|
|
|
entry = do_host_cpuid(array, function, i);
|
2020-03-02 23:56:19 +00:00
|
|
|
if (!entry)
|
2011-11-28 09:20:29 +00:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 23:56:11 +00:00
|
|
|
/*
|
2020-03-02 23:56:23 +00:00
|
|
|
* The supported check above should have filtered out
|
2020-03-05 15:11:56 +00:00
|
|
|
* invalid sub-leafs. Only valid sub-leafs should
|
2020-03-02 23:56:11 +00:00
|
|
|
* reach this point, and they should have a non-zero
|
2020-03-05 15:11:56 +00:00
|
|
|
* save state size. Furthermore, check whether the
|
2022-01-25 11:52:23 +00:00
|
|
|
* processor agrees with permitted_xcr0/permitted_xss
|
2020-03-05 15:11:56 +00:00
|
|
|
* on whether this is an XCR0- or IA32_XSS-managed area.
|
2020-03-02 23:56:11 +00:00
|
|
|
*/
|
2020-03-05 15:11:56 +00:00
|
|
|
if (WARN_ON_ONCE(!entry->eax || (entry->ecx & 0x1) != s_state)) {
|
2020-03-02 23:56:19 +00:00
|
|
|
--array->nent;
|
2020-03-02 23:56:09 +00:00
|
|
|
continue;
|
2020-03-02 23:56:12 +00:00
|
|
|
}
|
2022-01-17 07:45:31 +00:00
|
|
|
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_XFD))
|
|
|
|
entry->ecx &= ~BIT_ULL(2);
|
2020-03-02 23:56:19 +00:00
|
|
|
entry->edx = 0;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
break;
|
2022-01-05 12:35:15 +00:00
|
|
|
}
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
case 0x12:
|
|
|
|
/* Intel SGX */
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_SGX)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Index 0: Sub-features, MISCSELECT (a.k.a extended features)
|
|
|
|
* and max enclave sizes. The SGX sub-features and MISCSELECT
|
|
|
|
* are restricted by kernel and KVM capabilities (like most
|
|
|
|
* feature flags), while enclave size is unrestricted.
|
|
|
|
*/
|
|
|
|
cpuid_entry_override(entry, CPUID_12_EAX);
|
|
|
|
entry->ebx &= SGX_MISC_EXINFO;
|
|
|
|
|
|
|
|
entry = do_host_cpuid(array, function, 1);
|
|
|
|
if (!entry)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Index 1: SECS.ATTRIBUTES. ATTRIBUTES are restricted a la
|
|
|
|
* feature flags. Advertise all supported flags, including
|
|
|
|
* privileged attributes that require explicit opt-in from
|
|
|
|
* userspace. ATTRIBUTES.XFRM is not adjusted as userspace is
|
|
|
|
* expected to derive it from supported XCR0.
|
|
|
|
*/
|
2022-07-20 19:13:47 +00:00
|
|
|
entry->eax &= SGX_ATTR_PRIV_MASK | SGX_ATTR_UNPRIV_MASK;
|
KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC
Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest. Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.
When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest. With the exception of the provision key, all SGX
attribute bits may be exposed to the guest. Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.
Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-04-12 04:21:42 +00:00
|
|
|
entry->ebx &= 0;
|
|
|
|
break;
|
2018-10-24 08:05:11 +00:00
|
|
|
/* Intel PT */
|
2020-03-02 23:56:17 +00:00
|
|
|
case 0x14:
|
2020-03-02 23:56:55 +00:00
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT)) {
|
2020-03-02 23:56:26 +00:00
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
2018-10-24 08:05:11 +00:00
|
|
|
break;
|
2020-03-02 23:56:26 +00:00
|
|
|
}
|
2018-10-24 08:05:11 +00:00
|
|
|
|
2020-03-02 23:56:17 +00:00
|
|
|
for (i = 1, max_idx = entry->eax; i <= max_idx; ++i) {
|
2020-03-02 23:56:19 +00:00
|
|
|
if (!do_host_cpuid(array, function, i))
|
2018-10-24 08:05:11 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
break;
|
2022-01-05 12:35:27 +00:00
|
|
|
/* Intel AMX TILE */
|
|
|
|
case 0x1d:
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_AMX_TILE)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 1, max_idx = entry->eax; i <= max_idx; ++i) {
|
|
|
|
if (!do_host_cpuid(array, function, i))
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 0x1e: /* TMUL information */
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_AMX_TILE)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2011-11-23 14:30:32 +00:00
|
|
|
case KVM_CPUID_SIGNATURE: {
|
2021-11-05 09:51:01 +00:00
|
|
|
const u32 *sigptr = (const u32 *)KVM_SIGNATURE;
|
2012-05-02 14:55:56 +00:00
|
|
|
entry->eax = KVM_CPUID_FEATURES;
|
2011-11-23 14:30:32 +00:00
|
|
|
entry->ebx = sigptr[0];
|
|
|
|
entry->ecx = sigptr[1];
|
|
|
|
entry->edx = sigptr[2];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case KVM_CPUID_FEATURES:
|
|
|
|
entry->eax = (1 << KVM_FEATURE_CLOCKSOURCE) |
|
|
|
|
(1 << KVM_FEATURE_NOP_IO_DELAY) |
|
|
|
|
(1 << KVM_FEATURE_CLOCKSOURCE2) |
|
|
|
|
(1 << KVM_FEATURE_ASYNC_PF) |
|
2012-06-24 16:25:07 +00:00
|
|
|
(1 << KVM_FEATURE_PV_EOI) |
|
2013-08-26 08:48:34 +00:00
|
|
|
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
|
2017-12-13 01:33:04 +00:00
|
|
|
(1 << KVM_FEATURE_PV_UNHALT) |
|
2018-02-01 21:16:21 +00:00
|
|
|
(1 << KVM_FEATURE_PV_TLB_FLUSH) |
|
KVM: X86: Implement "send IPI" hypercall
Using hypercall to send IPIs by one vmexit instead of one by one for
xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster
mode. Intel guest can enter x2apic cluster mode when interrupt remmaping
is enabled in qemu, however, latest AMD EPYC still just supports xapic
mode which can get great improvement by Exit-less IPIs. This patchset
lets a guest send multicast IPIs, with at most 128 destinations per
hypercall in 64-bit mode and 64 vCPUs per hypercall in 32-bit mode.
Hardware: Xeon Skylake 2.5GHz, 2 sockets, 40 cores, 80 threads, the VM
is 80 vCPUs, IPI microbenchmark(https://lkml.org/lkml/2017/12/19/141):
x2apic cluster mode, vanilla
Dry-run: 0, 2392199 ns
Self-IPI: 6907514, 15027589 ns
Normal IPI: 223910476, 251301666 ns
Broadcast IPI: 0, 9282161150 ns
Broadcast lock: 0, 8812934104 ns
x2apic cluster mode, pv-ipi
Dry-run: 0, 2449341 ns
Self-IPI: 6720360, 15028732 ns
Normal IPI: 228643307, 255708477 ns
Broadcast IPI: 0, 7572293590 ns => 22% performance boost
Broadcast lock: 0, 8316124651 ns
x2apic physical mode, vanilla
Dry-run: 0, 3135933 ns
Self-IPI: 8572670, 17901757 ns
Normal IPI: 226444334, 255421709 ns
Broadcast IPI: 0, 19845070887 ns
Broadcast lock: 0, 19827383656 ns
x2apic physical mode, pv-ipi
Dry-run: 0, 2446381 ns
Self-IPI: 6788217, 15021056 ns
Normal IPI: 219454441, 249583458 ns
Broadcast IPI: 0, 7806540019 ns => 154% performance boost
Broadcast lock: 0, 9143618799 ns
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-07-23 06:39:54 +00:00
|
|
|
(1 << KVM_FEATURE_ASYNC_PF_VMEXIT) |
|
2019-06-03 22:52:44 +00:00
|
|
|
(1 << KVM_FEATURE_PV_SEND_IPI) |
|
2019-06-11 12:23:50 +00:00
|
|
|
(1 << KVM_FEATURE_POLL_CONTROL) |
|
2020-05-25 14:41:22 +00:00
|
|
|
(1 << KVM_FEATURE_PV_SCHED_YIELD) |
|
|
|
|
(1 << KVM_FEATURE_ASYNC_PF_INT);
|
2011-11-23 14:30:32 +00:00
|
|
|
|
|
|
|
if (sched_info_on())
|
|
|
|
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
|
|
|
|
|
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x80000000:
|
2021-10-28 17:26:38 +00:00
|
|
|
entry->eax = min(entry->eax, 0x80000021);
|
2021-10-21 21:19:27 +00:00
|
|
|
/*
|
2022-04-29 18:43:04 +00:00
|
|
|
* Serializing LFENCE is reported in a multitude of ways, and
|
|
|
|
* NullSegClearsBase is not reported in CPUID on Zen2; help
|
|
|
|
* userspace by providing the CPUID leaf ourselves.
|
|
|
|
*
|
|
|
|
* However, only do it if the host has CPUID leaf 0x8000001d.
|
|
|
|
* QEMU thinks that it can query the host blindly for that
|
|
|
|
* CPUID leaf if KVM reports that it supports 0x8000001d or
|
|
|
|
* above. The processor merrily returns values from the
|
|
|
|
* highest Intel leaf which QEMU tries to use as the guest's
|
|
|
|
* 0x8000001d. Even worse, this can result in an infinite
|
|
|
|
* loop if said highest leaf has no subleaves indexed by ECX.
|
2021-10-21 21:19:27 +00:00
|
|
|
*/
|
2022-04-29 18:43:04 +00:00
|
|
|
if (entry->eax >= 0x8000001d &&
|
|
|
|
(static_cpu_has(X86_FEATURE_LFENCE_RDTSC)
|
|
|
|
|| !static_cpu_has_bug(X86_BUG_NULL_SEG)))
|
2021-10-21 21:19:27 +00:00
|
|
|
entry->eax = max(entry->eax, 0x80000021);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
|
|
|
case 0x80000001:
|
2022-09-29 22:51:58 +00:00
|
|
|
entry->ebx &= ~GENMASK(27, 16);
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0001_EDX);
|
|
|
|
cpuid_entry_override(entry, CPUID_8000_0001_ECX);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
2020-04-15 01:23:20 +00:00
|
|
|
case 0x80000006:
|
2022-09-29 22:51:59 +00:00
|
|
|
/* Drop reserved bits, pass host L2 cache and TLB info. */
|
|
|
|
entry->edx &= ~GENMASK(17, 16);
|
2020-04-15 01:23:20 +00:00
|
|
|
break;
|
2014-04-27 01:30:23 +00:00
|
|
|
case 0x80000007: /* Advanced power management */
|
|
|
|
/* invariant TSC is CPUID.80000007H:EDX[8] */
|
|
|
|
entry->edx &= (1 << 8);
|
|
|
|
/* mask against host */
|
|
|
|
entry->edx &= boot_cpu_data.x86_power;
|
|
|
|
entry->eax = entry->ebx = entry->ecx = 0;
|
|
|
|
break;
|
2011-11-23 14:30:32 +00:00
|
|
|
case 0x80000008: {
|
|
|
|
unsigned g_phys_as = (entry->eax >> 16) & 0xff;
|
|
|
|
unsigned virt_as = max((entry->eax >> 8) & 0xff, 48U);
|
|
|
|
unsigned phys_as = entry->eax & 0xff;
|
|
|
|
|
2021-06-23 23:05:46 +00:00
|
|
|
/*
|
2021-06-23 23:05:47 +00:00
|
|
|
* If TDP (NPT) is disabled use the adjusted host MAXPHYADDR as
|
|
|
|
* the guest operates in the same PA space as the host, i.e.
|
|
|
|
* reductions in MAXPHYADDR for memory encryption affect shadow
|
|
|
|
* paging, too.
|
|
|
|
*
|
|
|
|
* If TDP is enabled but an explicit guest MAXPHYADDR is not
|
|
|
|
* provided, use the raw bare metal MAXPHYADDR as reductions to
|
|
|
|
* the HPAs do not affect GPAs.
|
2021-06-23 23:05:46 +00:00
|
|
|
*/
|
2021-06-23 23:05:47 +00:00
|
|
|
if (!tdp_enabled)
|
|
|
|
g_phys_as = boot_cpu_data.x86_phys_bits;
|
|
|
|
else if (!g_phys_as)
|
2011-11-23 14:30:32 +00:00
|
|
|
g_phys_as = phys_as;
|
2021-06-23 23:05:46 +00:00
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
entry->eax = g_phys_as | (virt_as << 8);
|
2022-09-29 22:52:00 +00:00
|
|
|
entry->ecx &= ~(GENMASK(31, 16) | GENMASK(11, 8));
|
2018-02-01 21:59:43 +00:00
|
|
|
entry->edx = 0;
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0008_EBX);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
|
|
|
}
|
2020-03-02 23:57:09 +00:00
|
|
|
case 0x8000000A:
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_SVM)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
entry->eax = 1; /* SVM revision 1 */
|
|
|
|
entry->ebx = 8; /* Lets support 8 ASIDs in case we add proper
|
|
|
|
ASID emulation to nested SVM */
|
|
|
|
entry->ecx = 0; /* Reserved */
|
|
|
|
cpuid_entry_override(entry, CPUID_8000_000A_EDX);
|
|
|
|
break;
|
2011-11-23 14:30:32 +00:00
|
|
|
case 0x80000019:
|
|
|
|
entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x8000001a:
|
2022-09-29 22:52:01 +00:00
|
|
|
entry->eax &= GENMASK(2, 0);
|
|
|
|
entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
2019-03-27 20:15:37 +00:00
|
|
|
case 0x8000001e:
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
2019-11-21 20:33:43 +00:00
|
|
|
case 0x8000001F:
|
2021-06-23 23:05:47 +00:00
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_SEV)) {
|
2019-11-21 20:33:43 +00:00
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
2021-06-23 23:05:47 +00:00
|
|
|
} else {
|
2021-04-22 02:11:15 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_001F_EAX);
|
2022-09-29 22:52:03 +00:00
|
|
|
/* Clear NumVMPL since KVM does not support VMPL. */
|
|
|
|
entry->ebx &= ~GENMASK(31, 12);
|
2021-06-23 23:05:47 +00:00
|
|
|
/*
|
|
|
|
* Enumerate '0' for "PA bits reduction", the adjusted
|
|
|
|
* MAXPHYADDR is enumerated directly (see 0x80000008).
|
|
|
|
*/
|
|
|
|
entry->ebx &= ~GENMASK(11, 6);
|
|
|
|
}
|
2019-11-21 20:33:43 +00:00
|
|
|
break;
|
2021-10-28 17:26:38 +00:00
|
|
|
case 0x80000020:
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x80000021:
|
|
|
|
entry->ebx = entry->ecx = entry->edx = 0;
|
2023-01-24 16:33:13 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0021_EAX);
|
2021-10-28 17:26:38 +00:00
|
|
|
break;
|
2011-11-23 14:30:32 +00:00
|
|
|
/*Add support for Centaur's CPUID instruction*/
|
|
|
|
case 0xC0000000:
|
|
|
|
/*Just support up to 0xC0000004 now*/
|
|
|
|
entry->eax = min(entry->eax, 0xC0000004);
|
|
|
|
break;
|
|
|
|
case 0xC0000001:
|
2020-03-02 23:56:53 +00:00
|
|
|
cpuid_entry_override(entry, CPUID_C000_0001_EDX);
|
2011-11-23 14:30:32 +00:00
|
|
|
break;
|
|
|
|
case 3: /* Processor serial number */
|
|
|
|
case 5: /* MONITOR/MWAIT */
|
|
|
|
case 0xC0000002:
|
|
|
|
case 0xC0000003:
|
|
|
|
case 0xC0000004:
|
|
|
|
default:
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-11-28 09:20:29 +00:00
|
|
|
r = 0;
|
|
|
|
|
|
|
|
out:
|
2011-11-23 14:30:32 +00:00
|
|
|
put_cpu();
|
2011-11-28 09:20:29 +00:00
|
|
|
|
|
|
|
return r;
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
static int do_cpuid_func(struct kvm_cpuid_array *array, u32 func,
|
|
|
|
unsigned int type)
|
2013-09-22 14:44:50 +00:00
|
|
|
{
|
|
|
|
if (type == KVM_GET_EMULATED_CPUID)
|
2020-03-02 23:56:19 +00:00
|
|
|
return __do_cpuid_func_emulated(array, func);
|
2013-09-22 14:44:50 +00:00
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
return __do_cpuid_func(array, func);
|
2013-09-22 14:44:50 +00:00
|
|
|
}
|
|
|
|
|
2020-03-02 23:56:06 +00:00
|
|
|
#define CENTAUR_CPUID_SIGNATURE 0xC0000000
|
2011-11-28 09:20:29 +00:00
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
static int get_cpuid_func(struct kvm_cpuid_array *array, u32 func,
|
|
|
|
unsigned int type)
|
2020-03-02 23:56:05 +00:00
|
|
|
{
|
|
|
|
u32 limit;
|
|
|
|
int r;
|
|
|
|
|
2020-03-02 23:56:06 +00:00
|
|
|
if (func == CENTAUR_CPUID_SIGNATURE &&
|
|
|
|
boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR)
|
|
|
|
return 0;
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
r = do_cpuid_func(array, func, type);
|
2020-03-02 23:56:05 +00:00
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
limit = array->entries[array->nent - 1].eax;
|
2020-03-02 23:56:05 +00:00
|
|
|
for (func = func + 1; func <= limit; ++func) {
|
2020-03-02 23:56:19 +00:00
|
|
|
r = do_cpuid_func(array, func, type);
|
2020-03-02 23:56:05 +00:00
|
|
|
if (r)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2013-09-22 14:44:50 +00:00
|
|
|
static bool sanity_check_entries(struct kvm_cpuid_entry2 __user *entries,
|
|
|
|
__u32 num_entries, unsigned int ioctl_type)
|
|
|
|
{
|
|
|
|
int i;
|
2013-11-06 14:46:02 +00:00
|
|
|
__u32 pad[3];
|
2013-09-22 14:44:50 +00:00
|
|
|
|
|
|
|
if (ioctl_type != KVM_GET_EMULATED_CPUID)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to make sure that ->padding is being passed clean from
|
|
|
|
* userspace in case we want to use it for something in the future.
|
|
|
|
*
|
|
|
|
* Sadly, this wasn't enforced for KVM_GET_SUPPORTED_CPUID and so we
|
|
|
|
* have to give ourselves satisfied only with the emulated side. /me
|
|
|
|
* sheds a tear.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < num_entries; i++) {
|
2013-11-06 14:46:02 +00:00
|
|
|
if (copy_from_user(pad, entries[i].padding, sizeof(pad)))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (pad[0] || pad[1] || pad[2])
|
2013-09-22 14:44:50 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
|
|
|
|
struct kvm_cpuid_entry2 __user *entries,
|
|
|
|
unsigned int type)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
2020-03-02 23:56:06 +00:00
|
|
|
static const u32 funcs[] = {
|
|
|
|
0, 0x80000000, CENTAUR_CPUID_SIGNATURE, KVM_CPUID_SIGNATURE,
|
2011-11-28 09:20:29 +00:00
|
|
|
};
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
struct kvm_cpuid_array array = {
|
|
|
|
.nent = 0,
|
|
|
|
};
|
|
|
|
int r, i;
|
2020-03-02 23:56:07 +00:00
|
|
|
|
2011-11-23 14:30:32 +00:00
|
|
|
if (cpuid->nent < 1)
|
2020-03-02 23:56:07 +00:00
|
|
|
return -E2BIG;
|
2011-11-23 14:30:32 +00:00
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
|
|
|
cpuid->nent = KVM_MAX_CPUID_ENTRIES;
|
2013-09-22 14:44:50 +00:00
|
|
|
|
|
|
|
if (sanity_check_entries(entries, cpuid->nent, type))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2022-11-03 01:17:49 +00:00
|
|
|
array.entries = kvcalloc(cpuid->nent, sizeof(struct kvm_cpuid_entry2), GFP_KERNEL);
|
2020-03-02 23:56:19 +00:00
|
|
|
if (!array.entries)
|
2020-03-02 23:56:07 +00:00
|
|
|
return -ENOMEM;
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2020-06-04 04:16:36 +00:00
|
|
|
array.maxnent = cpuid->nent;
|
|
|
|
|
2020-03-02 23:56:06 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(funcs); i++) {
|
2020-03-02 23:56:19 +00:00
|
|
|
r = get_cpuid_func(&array, funcs[i], type);
|
2011-11-28 09:20:29 +00:00
|
|
|
if (r)
|
2011-11-23 14:30:32 +00:00
|
|
|
goto out_free;
|
|
|
|
}
|
2020-03-02 23:56:19 +00:00
|
|
|
cpuid->nent = array.nent;
|
2011-11-23 14:30:32 +00:00
|
|
|
|
2020-03-02 23:56:19 +00:00
|
|
|
if (copy_to_user(entries, array.entries,
|
|
|
|
array.nent * sizeof(struct kvm_cpuid_entry2)))
|
2020-03-02 23:56:07 +00:00
|
|
|
r = -EFAULT;
|
2011-11-23 14:30:32 +00:00
|
|
|
|
|
|
|
out_free:
|
2022-03-08 09:57:39 +00:00
|
|
|
kvfree(array.entries);
|
2011-11-23 14:30:32 +00:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
struct kvm_cpuid_entry2 *kvm_find_cpuid_entry_index(struct kvm_vcpu *vcpu,
|
|
|
|
u32 function, u32 index)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
2020-10-01 13:05:39 +00:00
|
|
|
return cpuid_entry2_find(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent,
|
|
|
|
function, index);
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
2022-07-12 00:06:45 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_find_cpuid_entry_index);
|
|
|
|
|
|
|
|
struct kvm_cpuid_entry2 *kvm_find_cpuid_entry(struct kvm_vcpu *vcpu,
|
|
|
|
u32 function)
|
|
|
|
{
|
|
|
|
return cpuid_entry2_find(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent,
|
|
|
|
function, KVM_CPUID_INDEX_NOT_SIGNIFICANT);
|
|
|
|
}
|
2011-11-23 14:30:32 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_find_cpuid_entry);
|
|
|
|
|
|
|
|
/*
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
* Intel CPUID semantics treats any query for an out-of-range leaf as if the
|
|
|
|
* highest basic leaf (i.e. CPUID.0H:EAX) were requested. AMD CPUID semantics
|
|
|
|
* returns all zeroes for any undefined leaf, whether or not the leaf is in
|
|
|
|
* range. Centaur/VIA follows Intel semantics.
|
|
|
|
*
|
|
|
|
* A leaf is considered out-of-range if its function is higher than the maximum
|
|
|
|
* supported leaf of its associated class or if its associated class does not
|
|
|
|
* exist.
|
|
|
|
*
|
|
|
|
* There are three primary classes to be considered, with their respective
|
|
|
|
* ranges described as "<base> - <top>[,<base2> - <top2>] inclusive. A primary
|
|
|
|
* class exists if a guest CPUID entry for its <base> leaf exists. For a given
|
|
|
|
* class, CPUID.<base>.EAX contains the max supported leaf for the class.
|
|
|
|
*
|
|
|
|
* - Basic: 0x00000000 - 0x3fffffff, 0x50000000 - 0x7fffffff
|
|
|
|
* - Hypervisor: 0x40000000 - 0x4fffffff
|
|
|
|
* - Extended: 0x80000000 - 0xbfffffff
|
|
|
|
* - Centaur: 0xc0000000 - 0xcfffffff
|
|
|
|
*
|
|
|
|
* The Hypervisor class is further subdivided into sub-classes that each act as
|
2021-03-18 14:28:01 +00:00
|
|
|
* their own independent class associated with a 0x100 byte range. E.g. if Qemu
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
* is advertising support for both HyperV and KVM, the resulting Hypervisor
|
|
|
|
* CPUID sub-classes are:
|
|
|
|
*
|
|
|
|
* - HyperV: 0x40000000 - 0x400000ff
|
|
|
|
* - KVM: 0x40000100 - 0x400001ff
|
2011-11-23 14:30:32 +00:00
|
|
|
*/
|
2020-03-05 01:34:36 +00:00
|
|
|
static struct kvm_cpuid_entry2 *
|
|
|
|
get_out_of_range_cpuid_entry(struct kvm_vcpu *vcpu, u32 *fn_ptr, u32 index)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
struct kvm_cpuid_entry2 *basic, *class;
|
2020-03-05 01:34:36 +00:00
|
|
|
u32 function = *fn_ptr;
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
basic = kvm_find_cpuid_entry(vcpu, 0);
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
if (!basic)
|
2020-03-05 01:34:36 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (is_guest_vendor_amd(basic->ebx, basic->ecx, basic->edx) ||
|
|
|
|
is_guest_vendor_hygon(basic->ebx, basic->ecx, basic->edx))
|
|
|
|
return NULL;
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
|
|
|
|
if (function >= 0x40000000 && function <= 0x4fffffff)
|
2022-07-12 00:06:45 +00:00
|
|
|
class = kvm_find_cpuid_entry(vcpu, function & 0xffffff00);
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
else if (function >= 0xc0000000)
|
2022-07-12 00:06:45 +00:00
|
|
|
class = kvm_find_cpuid_entry(vcpu, 0xc0000000);
|
KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes
Rework the masking in the out-of-range CPUID logic to handle the
Hypervisor sub-classes, as well as the Centaur class if the guest
virtual CPU vendor is Centaur.
Masking against 0x80000000 only handles basic and extended leafs, which
results in Hypervisor range checks being performed against the basic
CPUID class, and Centuar range checks being performed against the
Extended class. E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
there is no entry for CPUID.0x40000006, then function 0x40000006 would
be incorrectly reported as out of bounds.
While there is no official definition of what constitutes a class, the
convention established for Hypervisor classes effectively uses bits 31:8
as the mask by virtue of checking for different bases in increments of
0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
when HyperV features are advertised at the default base of 0x40000000.
The bad range check doesn't cause functional problems for any known VMM
because out-of-range semantics only come into play if the exact entry
isn't found, and VMMs either support a very limited Hypervisor range,
e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
room for undefined leafs) or explicitly defines gaps to be zero, e.g.
Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
limits (the latter comes into play when providing HyperV features).
The bad behavior can be visually confirmed by dumping CPUID output in
the guest when running Qemu with a stable TSC, as Qemu extends the limit
of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
without defining zeroed entries for 0x40000002 - 0x4000000f.
Note, documentation of Centaur/VIA CPUs is hard to come by. Designating
0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
behavior of a real Centaur/VIA CPU.
Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-05 01:34:34 +00:00
|
|
|
else
|
2022-07-12 00:06:45 +00:00
|
|
|
class = kvm_find_cpuid_entry(vcpu, function & 0x80000000);
|
2019-09-26 00:04:17 +00:00
|
|
|
|
2020-03-05 01:34:36 +00:00
|
|
|
if (class && function <= class->eax)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Leaf specific adjustments are also applied when redirecting to the
|
|
|
|
* max basic entry, e.g. if the max basic leaf is 0xb but there is no
|
|
|
|
* entry for CPUID.0xb.index (see below), then the output value for EDX
|
|
|
|
* needs to be pulled from CPUID.0xb.1.
|
|
|
|
*/
|
|
|
|
*fn_ptr = basic->eax;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The class does not exist or the requested function is out of range;
|
|
|
|
* the effective CPUID entry is the max basic leaf. Note, the index of
|
|
|
|
* the original requested leaf is observed!
|
|
|
|
*/
|
2022-07-12 00:06:45 +00:00
|
|
|
return kvm_find_cpuid_entry_index(vcpu, basic->eax, index);
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
|
2017-08-24 12:27:52 +00:00
|
|
|
bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
|
2020-03-05 01:34:37 +00:00
|
|
|
u32 *ecx, u32 *edx, bool exact_only)
|
2011-11-23 14:30:32 +00:00
|
|
|
{
|
2020-03-05 01:34:31 +00:00
|
|
|
u32 orig_function = *eax, function = *eax, index = *ecx;
|
2019-09-26 00:04:17 +00:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2020-03-17 19:53:54 +00:00
|
|
|
bool exact, used_max_basic = false;
|
2017-08-24 12:27:52 +00:00
|
|
|
|
2022-07-12 00:06:45 +00:00
|
|
|
entry = kvm_find_cpuid_entry_index(vcpu, function, index);
|
2020-03-05 01:34:37 +00:00
|
|
|
exact = !!entry;
|
2020-03-05 01:34:36 +00:00
|
|
|
|
2020-03-17 19:53:54 +00:00
|
|
|
if (!entry && !exact_only) {
|
2020-03-05 01:34:36 +00:00
|
|
|
entry = get_out_of_range_cpuid_entry(vcpu, &function, index);
|
2020-03-17 19:53:54 +00:00
|
|
|
used_max_basic = !!entry;
|
|
|
|
}
|
2020-03-05 01:34:36 +00:00
|
|
|
|
2019-09-26 00:04:17 +00:00
|
|
|
if (entry) {
|
|
|
|
*eax = entry->eax;
|
|
|
|
*ebx = entry->ebx;
|
|
|
|
*ecx = entry->ecx;
|
|
|
|
*edx = entry->edx;
|
2019-11-18 17:23:00 +00:00
|
|
|
if (function == 7 && index == 0) {
|
|
|
|
u64 data;
|
|
|
|
if (!__kvm_get_msr(vcpu, MSR_IA32_TSX_CTRL, &data, true) &&
|
|
|
|
(data & TSX_CTRL_CPUID_CLEAR))
|
|
|
|
*ebx &= ~(F(RTM) | F(HLE));
|
|
|
|
}
|
2019-09-26 00:04:17 +00:00
|
|
|
} else {
|
2012-06-07 11:07:48 +00:00
|
|
|
*eax = *ebx = *ecx = *edx = 0;
|
2019-09-26 00:04:17 +00:00
|
|
|
/*
|
|
|
|
* When leaf 0BH or 1FH is defined, CL is pass-through
|
|
|
|
* and EDX is always the x2APIC ID, even for undefined
|
|
|
|
* subleaves. Index 1 will exist iff the leaf is
|
|
|
|
* implemented, so we pass through CL iff leaf 1
|
|
|
|
* exists. EDX can be copied from any existing index.
|
|
|
|
*/
|
|
|
|
if (function == 0xb || function == 0x1f) {
|
2022-07-12 00:06:45 +00:00
|
|
|
entry = kvm_find_cpuid_entry_index(vcpu, function, 1);
|
2019-09-26 00:04:17 +00:00
|
|
|
if (entry) {
|
|
|
|
*ecx = index & 0xff;
|
|
|
|
*edx = entry->edx;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-03-17 19:53:54 +00:00
|
|
|
trace_kvm_cpuid(orig_function, index, *eax, *ebx, *ecx, *edx, exact,
|
|
|
|
used_max_basic);
|
2020-03-05 01:34:37 +00:00
|
|
|
return exact;
|
2012-06-07 11:07:48 +00:00
|
|
|
}
|
2012-12-05 14:26:19 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_cpuid);
|
2012-06-07 11:07:48 +00:00
|
|
|
|
2016-11-29 20:40:37 +00:00
|
|
|
int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
|
2012-06-07 11:07:48 +00:00
|
|
|
{
|
2016-11-07 00:55:49 +00:00
|
|
|
u32 eax, ebx, ecx, edx;
|
2012-06-07 11:07:48 +00:00
|
|
|
|
2017-03-20 08:16:28 +00:00
|
|
|
if (cpuid_fault_enabled(vcpu) && !kvm_require_cpl(vcpu, 0))
|
|
|
|
return 1;
|
|
|
|
|
2019-04-30 17:36:17 +00:00
|
|
|
eax = kvm_rax_read(vcpu);
|
|
|
|
ecx = kvm_rcx_read(vcpu);
|
2020-03-05 01:34:37 +00:00
|
|
|
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx, false);
|
2019-04-30 17:36:17 +00:00
|
|
|
kvm_rax_write(vcpu, eax);
|
|
|
|
kvm_rbx_write(vcpu, ebx);
|
|
|
|
kvm_rcx_write(vcpu, ecx);
|
|
|
|
kvm_rdx_write(vcpu, edx);
|
KVM: x86: Add kvm_skip_emulated_instruction and use it.
kvm_skip_emulated_instruction calls both
kvm_x86_ops->skip_emulated_instruction and kvm_vcpu_check_singlestep,
skipping the emulated instruction and generating a trap if necessary.
Replacing skip_emulated_instruction calls with
kvm_skip_emulated_instruction is straightforward, except for:
- ICEBP, which is already inside a trap, so avoid triggering another trap.
- Instructions that can trigger exits to userspace, such as the IO insns,
MOVs to CR8, and HALT. If kvm_skip_emulated_instruction does trigger a
KVM_GUESTDBG_SINGLESTEP exit, and the handling code for
IN/OUT/MOV CR8/HALT also triggers an exit to userspace, the latter will
take precedence. The singlestep will be triggered again on the next
instruction, which is the current behavior.
- Task switch instructions which would require additional handling (e.g.
the task switch bit) and are instead left alone.
- Cases where VMLAUNCH/VMRESUME do not proceed to the next instruction,
which do not trigger singlestep traps as mentioned previously.
Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-11-29 20:40:40 +00:00
|
|
|
return kvm_skip_emulated_instruction(vcpu);
|
2011-11-23 14:30:32 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
|