2019-06-04 10:11:32 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-11-23 16:30:32 +02: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
|
|
|
|
*/
|
KVM: x86: Unify pr_fmt to use module name for all KVM modules
Define pr_fmt using KBUILD_MODNAME for all KVM x86 code so that printks
use consistent formatting across common x86, Intel, and AMD code. In
addition to providing consistent print formatting, using KBUILD_MODNAME,
e.g. kvm_amd and kvm_intel, allows referencing SVM and VMX (and SEV and
SGX and ...) as technologies without generating weird messages, and
without causing naming conflicts with other kernel code, e.g. "SEV: ",
"tdx: ", "sgx: " etc.. are all used by the kernel for non-KVM subsystems.
Opportunistically move away from printk() for prints that need to be
modified anyways, e.g. to drop a manual "kvm: " prefix.
Opportunistically convert a few SGX WARNs that are similarly modified to
WARN_ONCE; in the very unlikely event that the WARNs fire, odds are good
that they would fire repeatedly and spam the kernel log without providing
unique information in each print.
Note, defining pr_fmt yields undesirable results for code that uses KVM's
printk wrappers, e.g. vcpu_unimpl(). But, that's a pre-existing problem
as SVM/kvm_amd already defines a pr_fmt, and thankfully use of KVM's
wrappers is relatively limited in KVM x86 code.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Message-Id: <20221130230934.1014142-35-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-11-30 23:09:18 +00:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
#include <linux/kvm_host.h>
|
2023-08-15 13:36:53 -07:00
|
|
|
#include "linux/lockdep.h"
|
2016-07-13 20:19:00 -04:00
|
|
|
#include <linux/export.h>
|
2011-12-14 17:58:18 +01:00
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/uaccess.h>
|
2017-02-05 12:07:04 +01:00
|
|
|
#include <linux/sched/stat.h>
|
|
|
|
|
2016-11-07 14:03:20 +08:00
|
|
|
#include <asm/processor.h>
|
2011-11-23 16:30:32 +02:00
|
|
|
#include <asm/user.h>
|
2015-04-28 08:41:33 +02: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 16:21:42 +12:00
|
|
|
#include <asm/sgx.h>
|
2025-05-08 17:02:31 +02:00
|
|
|
#include <asm/cpuid/api.h>
|
2011-11-23 16:30:32 +02:00
|
|
|
#include "cpuid.h"
|
|
|
|
#include "lapic.h"
|
|
|
|
#include "mmu.h"
|
|
|
|
#include "trace.h"
|
2015-06-19 13:54:23 +02:00
|
|
|
#include "pmu.h"
|
2023-01-06 10:36:00 +00:00
|
|
|
#include "xen.h"
|
2011-11-23 16:30:32 +02: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 15:56:41 -08: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 16:21:35 +12: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 15:56:41 -08:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_cpu_caps);
|
|
|
|
|
KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init
Snapshot the output of CPUID.0xD.[1..n] during kvm.ko initiliaization to
avoid the overead of CPUID during runtime. The offset, size, and metadata
for CPUID.0xD.[1..n] sub-leaves does not depend on XCR0 or XSS values, i.e.
is constant for a given CPU, and thus can be cached during module load.
On Intel's Emerald Rapids, CPUID is *wildly* expensive, to the point where
recomputing XSAVE offsets and sizes results in a 4x increase in latency of
nested VM-Enter and VM-Exit (nested transitions can trigger
xstate_required_size() multiple times per transition), relative to using
cached values. The issue is easily visible by running `perf top` while
triggering nested transitions: kvm_update_cpuid_runtime() shows up at a
whopping 50%.
As measured via RDTSC from L2 (using KVM-Unit-Test's CPUID VM-Exit test
and a slightly modified L1 KVM to handle CPUID in the fastpath), a nested
roundtrip to emulate CPUID on Skylake (SKX), Icelake (ICX), and Emerald
Rapids (EMR) takes:
SKX 11650
ICX 22350
EMR 28850
Using cached values, the latency drops to:
SKX 6850
ICX 9000
EMR 7900
The underlying issue is that CPUID itself is slow on ICX, and comically
slow on EMR. The problem is exacerbated on CPUs which support XSAVES
and/or XSAVEC, as KVM invokes xstate_required_size() twice on each
runtime CPUID update, and because there are more supported XSAVE features
(CPUID for supported XSAVE feature sub-leafs is significantly slower).
SKX:
CPUID.0xD.2 = 348 cycles
CPUID.0xD.3 = 400 cycles
CPUID.0xD.4 = 276 cycles
CPUID.0xD.5 = 236 cycles
<other sub-leaves are similar>
EMR:
CPUID.0xD.2 = 1138 cycles
CPUID.0xD.3 = 1362 cycles
CPUID.0xD.4 = 1068 cycles
CPUID.0xD.5 = 910 cycles
CPUID.0xD.6 = 914 cycles
CPUID.0xD.7 = 1350 cycles
CPUID.0xD.8 = 734 cycles
CPUID.0xD.9 = 766 cycles
CPUID.0xD.10 = 732 cycles
CPUID.0xD.11 = 718 cycles
CPUID.0xD.12 = 734 cycles
CPUID.0xD.13 = 1700 cycles
CPUID.0xD.14 = 1126 cycles
CPUID.0xD.15 = 898 cycles
CPUID.0xD.16 = 716 cycles
CPUID.0xD.17 = 748 cycles
CPUID.0xD.18 = 776 cycles
Note, updating runtime CPUID information multiple times per nested
transition is itself a flaw, especially since CPUID is a mandotory
intercept on both Intel and AMD. E.g. KVM doesn't need to ensure emulated
CPUID state is up-to-date while running L2. That flaw will be fixed in a
future patch, as deferring runtime CPUID updates is more subtle than it
appears at first glance, the benefits aren't super critical to have once
the XSAVE issue is resolved, and caching CPUID output is desirable even if
KVM's updates are deferred.
Cc: Jim Mattson <jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20241211013302.1347853-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-10 17:32:58 -08:00
|
|
|
struct cpuid_xstate_sizes {
|
|
|
|
u32 eax;
|
|
|
|
u32 ebx;
|
|
|
|
u32 ecx;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct cpuid_xstate_sizes xstate_sizes[XFEATURE_MAX] __ro_after_init;
|
|
|
|
|
|
|
|
void __init kvm_init_xstate_sizes(void)
|
|
|
|
{
|
|
|
|
u32 ign;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = XFEATURE_YMM; i < ARRAY_SIZE(xstate_sizes); i++) {
|
|
|
|
struct cpuid_xstate_sizes *xs = &xstate_sizes[i];
|
|
|
|
|
|
|
|
cpuid_count(0xD, i, &xs->eax, &xs->ebx, &xs->ecx, &ign);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-05 04:35:29 -08:00
|
|
|
u32 xstate_required_size(u64 xstate_bv, bool compacted)
|
2013-10-02 16:06:16 +02:00
|
|
|
{
|
|
|
|
u32 ret = XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET;
|
2024-12-10 17:32:59 -08:00
|
|
|
int i;
|
2013-10-02 16:06:16 +02:00
|
|
|
|
2015-09-02 16:31:26 -07:00
|
|
|
xstate_bv &= XFEATURE_MASK_EXTEND;
|
2024-12-10 17:32:59 -08:00
|
|
|
for (i = XFEATURE_YMM; i < ARRAY_SIZE(xstate_sizes) && xstate_bv; i++) {
|
|
|
|
struct cpuid_xstate_sizes *xs = &xstate_sizes[i];
|
|
|
|
u32 offset;
|
|
|
|
|
|
|
|
if (!(xstate_bv & BIT_ULL(i)))
|
|
|
|
continue;
|
2013-10-02 16:06:16 +02:00
|
|
|
|
2024-12-10 17:32:59 -08:00
|
|
|
/* ECX[1]: 64B alignment in compacted form */
|
|
|
|
if (compacted)
|
|
|
|
offset = (xs->ecx & 0x2) ? ALIGN(ret, 64) : ret;
|
|
|
|
else
|
|
|
|
offset = xs->ebx;
|
|
|
|
ret = max(ret, offset + xs->eax);
|
|
|
|
xstate_bv &= ~BIT_ULL(i);
|
2013-10-02 16:06:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2025-01-22 06:31:31 -05:00
|
|
|
struct kvm_cpuid_entry2 *kvm_find_cpuid_entry2(
|
|
|
|
struct kvm_cpuid_entry2 *entries, int nent, u32 function, u64 index)
|
2020-10-01 15:05:39 +02:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *e;
|
|
|
|
int i;
|
|
|
|
|
2023-08-15 13:36:53 -07:00
|
|
|
/*
|
|
|
|
* KVM has a semi-arbitrary rule that querying the guest's CPUID model
|
|
|
|
* with IRQs disabled is disallowed. The CPUID model can legitimately
|
|
|
|
* have over one hundred entries, i.e. the lookup is slow, and IRQs are
|
|
|
|
* typically disabled in KVM only when KVM is in a performance critical
|
|
|
|
* path, e.g. the core VM-Enter/VM-Exit run loop. Nothing will break
|
|
|
|
* if this rule is violated, this assertion is purely to flag potential
|
|
|
|
* performance issues. If this fires, consider moving the lookup out
|
|
|
|
* of the hotpath, e.g. by caching information during CPUID updates.
|
|
|
|
*/
|
|
|
|
lockdep_assert_irqs_enabled();
|
|
|
|
|
2025-01-22 06:31:31 -05:00
|
|
|
for (i = 0; i < nent; i++) {
|
|
|
|
e = &entries[i];
|
2020-10-01 15:05:39 +02:00
|
|
|
|
2022-07-12 02:06:45 +02:00
|
|
|
if (e->function != function)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the index isn't significant, use the first entry with a
|
2024-01-02 18:40:11 -06:00
|
|
|
* matching function. It's userspace's responsibility to not
|
2022-07-12 02:06:45 +02:00
|
|
|
* 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 15:05:39 +02:00
|
|
|
return e;
|
2022-07-12 02:06:45 +02:00
|
|
|
}
|
2020-10-01 15:05:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2025-01-22 06:31:31 -05:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_find_cpuid_entry2);
|
2024-11-27 17:34:03 -08:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
static int kvm_check_cpuid(struct kvm_vcpu *vcpu)
|
2020-07-09 12:34:22 +08:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
2022-01-05 04:35:19 -08:00
|
|
|
u64 xfeatures;
|
2020-07-09 12:34:22 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The existing code assumes virtual address is 48-bit or 57-bit in the
|
|
|
|
* canonical address checks; exit if it is ever changed.
|
|
|
|
*/
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000008);
|
2020-07-09 12:34:22 +08: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 04:35:19 -08:00
|
|
|
/*
|
|
|
|
* Exposing dynamic xfeatures to the guest requires additional
|
|
|
|
* enabling in the FPU, e.g. to expand the guest XSAVE state size.
|
|
|
|
*/
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry_index(vcpu, 0xd, 0);
|
2022-01-05 04:35:19 -08:00
|
|
|
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 12:34:22 +08:00
|
|
|
}
|
|
|
|
|
2024-11-27 17:33:59 -08:00
|
|
|
static u32 kvm_apply_cpuid_pv_features_quirk(struct kvm_vcpu *vcpu);
|
KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation
Defer runtime CPUID updates until the next non-faulting CPUID emulation
or KVM_GET_CPUID2, which are the only paths in KVM that consume the
dynamic entries. Deferring the updates is especially beneficial to
nested VM-Enter/VM-Exit, as KVM will almost always detect multiple state
changes, not to mention the updates don't need to be realized while L2 is
active if CPUID is being intercepted by L1 (CPUID is a mandatory intercept
on Intel, but not AMD).
Deferring CPUID updates shaves several hundred cycles from nested VMX
roundtrips, as measured from L2 executing CPUID in a tight loop:
SKX 6850 => 6450
ICX 9000 => 8800
EMR 7900 => 7700
Alternatively, KVM could update only the CPUID leaves that are affected
by the state change, e.g. update XSAVE info only if XCR0 or XSS changes,
but that adds non-trivial complexity and doesn't solve the underlying
problem of nested transitions potentially changing both XCR0 and XSS, on
both nested VM-Enter and VM-Exit.
Skipping updates entirely if L2 is active and CPUID is being intercepted
by L1 could work for the common case. However, simply skipping updates if
L2 is active is *very* subtly dangerous and complex. Most KVM updates are
triggered by changes to the current vCPU state, which may be L2 state,
whereas performing updates only for L1 would requiring detecting changes
to L1 state. KVM would need to either track relevant L1 state, or defer
runtime CPUID updates until the next nested VM-Exit. The former is ugly
and complex, while the latter comes with similar dangers to deferring all
CPUID updates, and would only address the nested VM-Enter path.
To guard against using stale data, disallow querying dynamic CPUID feature
bits, i.e. features that KVM updates at runtime, via a compile-time
assertion in guest_cpu_cap_has(). Exempt MWAIT from the rule, as the
MISC_ENABLE_NO_MWAIT means that MWAIT is _conditionally_ a dynamic CPUID
feature.
Note, the rule could be enforced for MWAIT as well, e.g. by querying guest
CPUID in kvm_emulate_monitor_mwait, but there's no obvious advtantage to
doing so, and allowing MWAIT for guest_cpuid_has() opens up a different can
of worms. MONITOR/MWAIT can't be virtualized (for a reasonable definition),
and the nature of the MWAIT_NEVER_UD_FAULTS and MISC_ENABLE_NO_MWAIT quirks
means checking X86_FEATURE_MWAIT outside of kvm_emulate_monitor_mwait() is
wrong for other reasons.
Beyond the aforementioned feature bits, the only other dynamic CPUID
(sub)leaves are the XSAVE sizes, and similar to MWAIT, consuming those
CPUID entries in KVM is all but guaranteed to be a bug. The layout for an
actual XSAVE buffer depends on the format (compacted or not) and
potentially the features that are actually enabled. E.g. see the logic in
fpstate_clear_xstate_component() needed to poke into the guest's effective
XSAVE state to clear MPX state on INIT. KVM does consume
CPUID.0xD.0.{EAX,EDX} in kvm_check_cpuid() and cpuid_get_supported_xcr0(),
but not EBX, which is the only dynamic output register in the leaf.
Link: https://lore.kernel.org/r/20241211013302.1347853-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-12-10 17:33:02 -08:00
|
|
|
static void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu);
|
2024-11-27 17:33:59 -08:00
|
|
|
|
2022-01-17 16:05:40 +01: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;
|
|
|
|
|
2024-11-27 17:33:31 -08:00
|
|
|
/*
|
|
|
|
* Apply runtime CPUID updates to the incoming CPUID entries to avoid
|
2024-11-27 17:34:00 -08:00
|
|
|
* false positives due mismatches on KVM-owned feature flags.
|
2024-11-27 17:33:58 -08:00
|
|
|
*
|
|
|
|
* Note! @e2 and @nent track the _old_ CPUID entries!
|
2024-11-27 17:33:31 -08:00
|
|
|
*/
|
2024-11-27 17:33:58 -08:00
|
|
|
kvm_update_cpuid_runtime(vcpu);
|
2024-11-27 17:33:59 -08:00
|
|
|
kvm_apply_cpuid_pv_features_quirk(vcpu);
|
2024-11-27 17:33:31 -08:00
|
|
|
|
2022-01-17 16:05:40 +01:00
|
|
|
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 14:18:04 +01:00
|
|
|
e2[i].flags != orig->flags ||
|
2022-01-17 16:05:40 +01: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;
|
|
|
|
}
|
|
|
|
|
2024-11-27 17:34:01 -08:00
|
|
|
static struct kvm_hypervisor_cpuid kvm_get_hypervisor_cpuid(struct kvm_vcpu *vcpu,
|
|
|
|
const char *sig)
|
2020-10-27 16:10:42 -07:00
|
|
|
{
|
2023-01-06 10:35:59 +00:00
|
|
|
struct kvm_hypervisor_cpuid cpuid = {};
|
2021-11-05 09:51:01 +00:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2023-01-06 10:35:59 +00:00
|
|
|
u32 base;
|
2021-11-05 09:51:01 +00:00
|
|
|
|
2025-05-15 22:28:59 +02:00
|
|
|
for_each_possible_cpuid_base_hypervisor(base) {
|
2024-11-27 17:34:03 -08:00
|
|
|
entry = kvm_find_cpuid_entry(vcpu, base);
|
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;
|
|
|
|
|
2023-01-06 10:35:59 +00:00
|
|
|
if (!memcmp(signature, sig, sizeof(signature))) {
|
|
|
|
cpuid.base = base;
|
|
|
|
cpuid.limit = entry->eax;
|
2021-11-05 09:51:01 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2023-01-06 10:35:59 +00:00
|
|
|
|
|
|
|
return cpuid;
|
2021-11-05 09:51:01 +00:00
|
|
|
}
|
|
|
|
|
2024-11-27 17:33:59 -08:00
|
|
|
static u32 kvm_apply_cpuid_pv_features_quirk(struct kvm_vcpu *vcpu)
|
2024-02-28 11:18:35 +01:00
|
|
|
{
|
2024-11-27 17:34:00 -08:00
|
|
|
struct kvm_hypervisor_cpuid kvm_cpuid;
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
2024-02-28 11:18:36 +01:00
|
|
|
|
2024-11-27 17:34:00 -08:00
|
|
|
kvm_cpuid = kvm_get_hypervisor_cpuid(vcpu, KVM_SIGNATURE);
|
|
|
|
if (!kvm_cpuid.base)
|
|
|
|
return 0;
|
2024-02-28 11:18:36 +01:00
|
|
|
|
2024-11-27 17:34:00 -08:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, kvm_cpuid.base | KVM_CPUID_FEATURES);
|
2024-11-27 17:33:59 -08:00
|
|
|
if (!best)
|
|
|
|
return 0;
|
2020-10-27 16:10:42 -07:00
|
|
|
|
2024-11-27 17:33:59 -08:00
|
|
|
if (kvm_hlt_in_guest(vcpu->kvm))
|
|
|
|
best->eax &= ~(1 << KVM_FEATURE_PV_UNHALT);
|
2020-10-27 16:10:42 -07:00
|
|
|
|
2024-11-27 17:33:59 -08:00
|
|
|
return best->eax;
|
2020-10-27 16:10:42 -07:00
|
|
|
}
|
|
|
|
|
2022-01-24 11:36:05 +01:00
|
|
|
/*
|
|
|
|
* Calculate guest's supported XCR0 taking into account guest CPUID data and
|
2022-05-24 21:56:23 +08:00
|
|
|
* KVM's supported XCR0 (comprised of host's XCR0 and KVM_SUPPORTED_XCR0).
|
2022-01-24 11:36:05 +01:00
|
|
|
*/
|
2024-11-27 17:34:01 -08:00
|
|
|
static u64 cpuid_get_supported_xcr0(struct kvm_vcpu *vcpu)
|
2022-01-24 11:36:05 +01:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry_index(vcpu, 0xd, 0);
|
2022-01-24 11:36:05 +01:00
|
|
|
if (!best)
|
|
|
|
return 0;
|
|
|
|
|
2022-05-24 21:56:23 +08:00
|
|
|
return (best->eax | ((u64)best->edx << 32)) & kvm_caps.supported_xcr0;
|
2022-01-24 11:36:05 +01:00
|
|
|
}
|
|
|
|
|
2024-11-27 17:34:15 -08:00
|
|
|
static __always_inline void kvm_update_feature_runtime(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid_entry2 *entry,
|
|
|
|
unsigned int x86_feature,
|
|
|
|
bool has_feature)
|
|
|
|
{
|
|
|
|
cpuid_entry_change(entry, x86_feature, has_feature);
|
|
|
|
guest_cpu_cap_change(vcpu, x86_feature, has_feature);
|
|
|
|
}
|
|
|
|
|
KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation
Defer runtime CPUID updates until the next non-faulting CPUID emulation
or KVM_GET_CPUID2, which are the only paths in KVM that consume the
dynamic entries. Deferring the updates is especially beneficial to
nested VM-Enter/VM-Exit, as KVM will almost always detect multiple state
changes, not to mention the updates don't need to be realized while L2 is
active if CPUID is being intercepted by L1 (CPUID is a mandatory intercept
on Intel, but not AMD).
Deferring CPUID updates shaves several hundred cycles from nested VMX
roundtrips, as measured from L2 executing CPUID in a tight loop:
SKX 6850 => 6450
ICX 9000 => 8800
EMR 7900 => 7700
Alternatively, KVM could update only the CPUID leaves that are affected
by the state change, e.g. update XSAVE info only if XCR0 or XSS changes,
but that adds non-trivial complexity and doesn't solve the underlying
problem of nested transitions potentially changing both XCR0 and XSS, on
both nested VM-Enter and VM-Exit.
Skipping updates entirely if L2 is active and CPUID is being intercepted
by L1 could work for the common case. However, simply skipping updates if
L2 is active is *very* subtly dangerous and complex. Most KVM updates are
triggered by changes to the current vCPU state, which may be L2 state,
whereas performing updates only for L1 would requiring detecting changes
to L1 state. KVM would need to either track relevant L1 state, or defer
runtime CPUID updates until the next nested VM-Exit. The former is ugly
and complex, while the latter comes with similar dangers to deferring all
CPUID updates, and would only address the nested VM-Enter path.
To guard against using stale data, disallow querying dynamic CPUID feature
bits, i.e. features that KVM updates at runtime, via a compile-time
assertion in guest_cpu_cap_has(). Exempt MWAIT from the rule, as the
MISC_ENABLE_NO_MWAIT means that MWAIT is _conditionally_ a dynamic CPUID
feature.
Note, the rule could be enforced for MWAIT as well, e.g. by querying guest
CPUID in kvm_emulate_monitor_mwait, but there's no obvious advtantage to
doing so, and allowing MWAIT for guest_cpuid_has() opens up a different can
of worms. MONITOR/MWAIT can't be virtualized (for a reasonable definition),
and the nature of the MWAIT_NEVER_UD_FAULTS and MISC_ENABLE_NO_MWAIT quirks
means checking X86_FEATURE_MWAIT outside of kvm_emulate_monitor_mwait() is
wrong for other reasons.
Beyond the aforementioned feature bits, the only other dynamic CPUID
(sub)leaves are the XSAVE sizes, and similar to MWAIT, consuming those
CPUID entries in KVM is all but guaranteed to be a bug. The layout for an
actual XSAVE buffer depends on the format (compacted or not) and
potentially the features that are actually enabled. E.g. see the logic in
fpstate_clear_xstate_component() needed to poke into the guest's effective
XSAVE state to clear MPX state on INIT. KVM does consume
CPUID.0xD.0.{EAX,EDX} in kvm_check_cpuid() and cpuid_get_supported_xcr0(),
but not EBX, which is the only dynamic output register in the leaf.
Link: https://lore.kernel.org/r/20241211013302.1347853-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-12-10 17:33:02 -08:00
|
|
|
static void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu)
|
2011-11-23 16:30:32 +02:00
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation
Defer runtime CPUID updates until the next non-faulting CPUID emulation
or KVM_GET_CPUID2, which are the only paths in KVM that consume the
dynamic entries. Deferring the updates is especially beneficial to
nested VM-Enter/VM-Exit, as KVM will almost always detect multiple state
changes, not to mention the updates don't need to be realized while L2 is
active if CPUID is being intercepted by L1 (CPUID is a mandatory intercept
on Intel, but not AMD).
Deferring CPUID updates shaves several hundred cycles from nested VMX
roundtrips, as measured from L2 executing CPUID in a tight loop:
SKX 6850 => 6450
ICX 9000 => 8800
EMR 7900 => 7700
Alternatively, KVM could update only the CPUID leaves that are affected
by the state change, e.g. update XSAVE info only if XCR0 or XSS changes,
but that adds non-trivial complexity and doesn't solve the underlying
problem of nested transitions potentially changing both XCR0 and XSS, on
both nested VM-Enter and VM-Exit.
Skipping updates entirely if L2 is active and CPUID is being intercepted
by L1 could work for the common case. However, simply skipping updates if
L2 is active is *very* subtly dangerous and complex. Most KVM updates are
triggered by changes to the current vCPU state, which may be L2 state,
whereas performing updates only for L1 would requiring detecting changes
to L1 state. KVM would need to either track relevant L1 state, or defer
runtime CPUID updates until the next nested VM-Exit. The former is ugly
and complex, while the latter comes with similar dangers to deferring all
CPUID updates, and would only address the nested VM-Enter path.
To guard against using stale data, disallow querying dynamic CPUID feature
bits, i.e. features that KVM updates at runtime, via a compile-time
assertion in guest_cpu_cap_has(). Exempt MWAIT from the rule, as the
MISC_ENABLE_NO_MWAIT means that MWAIT is _conditionally_ a dynamic CPUID
feature.
Note, the rule could be enforced for MWAIT as well, e.g. by querying guest
CPUID in kvm_emulate_monitor_mwait, but there's no obvious advtantage to
doing so, and allowing MWAIT for guest_cpuid_has() opens up a different can
of worms. MONITOR/MWAIT can't be virtualized (for a reasonable definition),
and the nature of the MWAIT_NEVER_UD_FAULTS and MISC_ENABLE_NO_MWAIT quirks
means checking X86_FEATURE_MWAIT outside of kvm_emulate_monitor_mwait() is
wrong for other reasons.
Beyond the aforementioned feature bits, the only other dynamic CPUID
(sub)leaves are the XSAVE sizes, and similar to MWAIT, consuming those
CPUID entries in KVM is all but guaranteed to be a bug. The layout for an
actual XSAVE buffer depends on the format (compacted or not) and
potentially the features that are actually enabled. E.g. see the logic in
fpstate_clear_xstate_component() needed to poke into the guest's effective
XSAVE state to clear MPX state on INIT. KVM does consume
CPUID.0xD.0.{EAX,EDX} in kvm_check_cpuid() and cpuid_get_supported_xcr0(),
but not EBX, which is the only dynamic output register in the leaf.
Link: https://lore.kernel.org/r/20241211013302.1347853-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-12-10 17:33:02 -08:00
|
|
|
vcpu->arch.cpuid_dynamic_bits_dirty = false;
|
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 1);
|
2020-07-08 14:50:48 +08:00
|
|
|
if (best) {
|
2024-11-27 17:34:15 -08:00
|
|
|
kvm_update_feature_runtime(vcpu, best, X86_FEATURE_OSXSAVE,
|
2023-03-22 12:58:21 +08:00
|
|
|
kvm_is_cr4_bit_set(vcpu, X86_CR4_OSXSAVE));
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2024-11-27 17:34:15 -08:00
|
|
|
kvm_update_feature_runtime(vcpu, best, X86_FEATURE_APIC,
|
|
|
|
vcpu->arch.apic_base & MSR_IA32_APICBASE_ENABLE);
|
2024-11-27 17:34:12 -08:00
|
|
|
|
|
|
|
if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT))
|
2024-11-27 17:34:15 -08:00
|
|
|
kvm_update_feature_runtime(vcpu, best, X86_FEATURE_MWAIT,
|
|
|
|
vcpu->arch.ia32_misc_enable_msr &
|
|
|
|
MSR_IA32_MISC_ENABLE_MWAIT);
|
2020-07-08 14:50:48 +08:00
|
|
|
}
|
2016-11-09 09:50:11 -08:00
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry_index(vcpu, 7, 0);
|
2024-11-27 17:34:14 -08:00
|
|
|
if (best)
|
2024-11-27 17:34:15 -08:00
|
|
|
kvm_update_feature_runtime(vcpu, best, X86_FEATURE_OSPKE,
|
|
|
|
kvm_is_cr4_bit_set(vcpu, X86_CR4_PKE));
|
|
|
|
|
2016-03-22 16:51:21 +08:00
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry_index(vcpu, 0xD, 0);
|
2020-07-09 12:34:23 +08:00
|
|
|
if (best)
|
2020-04-29 23:43:12 +08:00
|
|
|
best->ebx = xstate_required_size(vcpu->arch.xcr0, false);
|
2013-10-02 16:06:15 +02:00
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
best = kvm_find_cpuid_entry_index(vcpu, 0xD, 1);
|
2020-03-02 15:56:30 -08:00
|
|
|
if (best && (cpuid_entry_has(best, X86_FEATURE_XSAVES) ||
|
|
|
|
cpuid_entry_has(best, X86_FEATURE_XSAVEC)))
|
2014-12-03 14:38:01 +01:00
|
|
|
best->ebx = xstate_required_size(vcpu->arch.xcr0, true);
|
2022-01-17 16:05:39 +01:00
|
|
|
}
|
2020-07-09 12:34:23 +08:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
static bool kvm_cpuid_has_hyperv(struct kvm_vcpu *vcpu)
|
2022-08-30 15:37:09 +02:00
|
|
|
{
|
2023-12-05 11:36:26 +01:00
|
|
|
#ifdef CONFIG_KVM_HYPERV
|
2022-08-30 15:37:09 +02:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
2024-11-27 17:34:03 -08:00
|
|
|
entry = kvm_find_cpuid_entry(vcpu, HYPERV_CPUID_INTERFACE);
|
2022-08-30 15:37:09 +02:00
|
|
|
return entry && entry->eax == HYPERV_CPUID_SIGNATURE_EAX;
|
2023-12-05 11:36:26 +01:00
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
2022-08-30 15:37:09 +02:00
|
|
|
}
|
|
|
|
|
2024-04-05 16:56:03 -07:00
|
|
|
static bool guest_cpuid_is_amd_or_hygon(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *entry;
|
|
|
|
|
|
|
|
entry = kvm_find_cpuid_entry(vcpu, 0);
|
|
|
|
if (!entry)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return is_guest_vendor_amd(entry->ebx, entry->ecx, entry->edx) ||
|
|
|
|
is_guest_vendor_hygon(entry->ebx, entry->ecx, entry->edx);
|
|
|
|
}
|
|
|
|
|
2024-11-27 17:34:08 -08:00
|
|
|
/*
|
|
|
|
* This isn't truly "unsafe", but except for the cpu_caps initialization code,
|
|
|
|
* all register lookups should use __cpuid_entry_get_reg(), which provides
|
|
|
|
* compile-time validation of the input.
|
|
|
|
*/
|
|
|
|
static u32 cpuid_get_reg_unsafe(struct kvm_cpuid_entry2 *entry, u32 reg)
|
|
|
|
{
|
|
|
|
switch (reg) {
|
|
|
|
case CPUID_EAX:
|
|
|
|
return entry->eax;
|
|
|
|
case CPUID_EBX:
|
|
|
|
return entry->ebx;
|
|
|
|
case CPUID_ECX:
|
|
|
|
return entry->ecx;
|
|
|
|
case CPUID_EDX:
|
|
|
|
return entry->edx;
|
|
|
|
default:
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-11-27 17:34:11 -08:00
|
|
|
static int cpuid_func_emulated(struct kvm_cpuid_entry2 *entry, u32 func,
|
|
|
|
bool include_partially_emulated);
|
|
|
|
|
KVM: x86: Do all post-set CPUID processing during vCPU creation
During vCPU creation, process KVM's default, empty CPUID as if userspace
set an empty CPUID to ensure consistent and correct behavior with respect
to guest CPUID. E.g. if userspace never sets guest CPUID, KVM will never
configure cr4_guest_rsvd_bits, and thus create divergent, incorrect, guest-
visible behavior due to letting the guest set any KVM-supported CR4 bits
despite the features not being allowed per guest CPUID.
Note! This changes KVM's ABI, as lack of full CPUID processing allowed
userspace to stuff garbage vCPU state, e.g. userspace could set CR4 to a
guest-unsupported value via KVM_SET_SREGS. But it's extremely unlikely
that this is a breaking change, as KVM already has many flows that require
userspace to set guest CPUID before loading vCPU state. E.g. multiple MSR
flows consult guest CPUID on host writes, and KVM_SET_SREGS itself already
relies on guest CPUID being up-to-date, as KVM's validity check on CR3
consumes CPUID.0x7.1 (for LAM) and CPUID.0x80000008 (for MAXPHYADDR).
Furthermore, the plan is to commit to enforcing guest CPUID for userspace
writes to MSRs, at which point bypassing sregs CPUID checks is even more
nonsensical.
Link: https://lore.kernel.org/r/20241128013424.4096668-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:33:30 -08:00
|
|
|
void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
|
2020-07-09 12:34:23 +08:00
|
|
|
{
|
|
|
|
struct kvm_lapic *apic = vcpu->arch.apic;
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
2024-11-27 17:34:08 -08:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2023-08-15 13:36:40 -07:00
|
|
|
bool allow_gbpages;
|
2024-11-27 17:34:08 -08:00
|
|
|
int i;
|
2020-07-09 12:34:23 +08:00
|
|
|
|
2024-11-27 17:34:07 -08:00
|
|
|
memset(vcpu->arch.cpu_caps, 0, sizeof(vcpu->arch.cpu_caps));
|
2024-11-27 17:34:08 -08:00
|
|
|
BUILD_BUG_ON(ARRAY_SIZE(reverse_cpuid) != NR_KVM_CPU_CAPS);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset guest capabilities to userspace's guest CPUID definition, i.e.
|
|
|
|
* honor userspace's definition for features that don't require KVM or
|
|
|
|
* hardware management/support (or that KVM simply doesn't care about).
|
|
|
|
*/
|
|
|
|
for (i = 0; i < NR_KVM_CPU_CAPS; i++) {
|
|
|
|
const struct cpuid_reg cpuid = reverse_cpuid[i];
|
2024-11-27 17:34:11 -08:00
|
|
|
struct kvm_cpuid_entry2 emulated;
|
2024-11-27 17:34:08 -08:00
|
|
|
|
|
|
|
if (!cpuid.function)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
entry = kvm_find_cpuid_entry_index(vcpu, cpuid.function, cpuid.index);
|
|
|
|
if (!entry)
|
|
|
|
continue;
|
|
|
|
|
2024-11-27 17:34:11 -08:00
|
|
|
cpuid_func_emulated(&emulated, cpuid.function, true);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A vCPU has a feature if it's supported by KVM and is enabled
|
|
|
|
* in guest CPUID. Note, this includes features that are
|
|
|
|
* supported by KVM but aren't advertised to userspace!
|
|
|
|
*/
|
|
|
|
vcpu->arch.cpu_caps[i] = kvm_cpu_caps[i] |
|
|
|
|
cpuid_get_reg_unsafe(&emulated, cpuid.reg);
|
|
|
|
vcpu->arch.cpu_caps[i] &= cpuid_get_reg_unsafe(entry, cpuid.reg);
|
2024-11-27 17:34:08 -08:00
|
|
|
}
|
2023-08-15 13:36:39 -07:00
|
|
|
|
2024-11-27 17:33:31 -08:00
|
|
|
kvm_update_cpuid_runtime(vcpu);
|
2023-08-15 13:36:39 -07:00
|
|
|
|
2023-08-15 13:36:40 -07:00
|
|
|
/*
|
|
|
|
* If TDP is enabled, let the guest use GBPAGES if they're supported in
|
|
|
|
* hardware. The hardware page walker doesn't let KVM disable GBPAGES,
|
|
|
|
* i.e. won't treat them as reserved, and KVM doesn't redo the GVA->GPA
|
|
|
|
* walk for performance and complexity reasons. Not to mention KVM
|
|
|
|
* _can't_ solve the problem because GVA->GPA walks aren't visible to
|
|
|
|
* KVM once a TDP translation is installed. Mimic hardware behavior so
|
|
|
|
* that KVM's is at least consistent, i.e. doesn't randomly inject #PF.
|
|
|
|
* If TDP is disabled, honor *only* guest CPUID as KVM has full control
|
|
|
|
* and can install smaller shadow pages if the host lacks 1GiB support.
|
|
|
|
*/
|
|
|
|
allow_gbpages = tdp_enabled ? boot_cpu_has(X86_FEATURE_GBPAGES) :
|
KVM: x86: Replace (almost) all guest CPUID feature queries with cpu_caps
Switch all queries (except XSAVES) of guest features from guest CPUID to
guest capabilities, i.e. replace all calls to guest_cpuid_has() with calls
to guest_cpu_cap_has().
Keep guest_cpuid_has() around for XSAVES, but subsume its helper
guest_cpuid_get_register() and add a compile-time assertion to prevent
using guest_cpuid_has() for any other feature. Add yet another comment
for XSAVE to explain why KVM is allowed to query its raw guest CPUID.
Opportunistically drop the unused guest_cpuid_clear(), as there should be
no circumstance in which KVM needs to _clear_ a guest CPUID feature now
that everything is tracked via cpu_caps. E.g. KVM may need to _change_
a feature to emulate dynamic CPUID flags, but KVM should never need to
clear a feature in guest CPUID to prevent it from being used by the guest.
Delete the last remnants of the governed features framework, as the lone
holdout was vmx_adjust_secondary_exec_control()'s divergent behavior for
governed vs. ungoverned features.
Note, replacing guest_cpuid_has() checks with guest_cpu_cap_has() when
computing reserved CR4 bits is a nop when viewed as a whole, as KVM's
capabilities are already incorporated into the calculation, i.e. if a
feature is present in guest CPUID but unsupported by KVM, its CR4 bit
was already being marked as reserved, checking guest_cpu_cap_has() simply
double-stamps that it's a reserved bit.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-51-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:17 -08:00
|
|
|
guest_cpu_cap_has(vcpu, X86_FEATURE_GBPAGES);
|
2024-11-27 17:34:08 -08:00
|
|
|
guest_cpu_cap_change(vcpu, X86_FEATURE_GBPAGES, allow_gbpages);
|
2020-07-09 12:34:23 +08:00
|
|
|
|
2022-07-12 02:06:45 +02:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 1);
|
2020-07-09 12:34:23 +08: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);
|
|
|
|
}
|
|
|
|
|
2024-11-27 17:34:01 -08:00
|
|
|
vcpu->arch.guest_supported_xcr0 = cpuid_get_supported_xcr0(vcpu);
|
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 16:21:42 +12:00
|
|
|
|
2024-11-27 17:33:59 -08:00
|
|
|
vcpu->arch.pv_cpuid.features = kvm_apply_cpuid_pv_features_quirk(vcpu);
|
2020-10-27 16:10:42 -07:00
|
|
|
|
KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel compatible
Add kvm_vcpu_arch.is_amd_compatible to cache if a vCPU's vendor model is
compatible with AMD, i.e. if the vCPU vendor is AMD or Hygon, along with
helpers to check if a vCPU is compatible AMD vs. Intel. To handle Intel
vs. AMD behavior related to masking the LVTPC entry, KVM will need to
check for vendor compatibility on every PMI injection, i.e. querying for
AMD will soon be a moderately hot path.
Note! This subtly (or maybe not-so-subtly) makes "Intel compatible" KVM's
default behavior, both if userspace omits (or never sets) CPUID 0x0 and if
userspace sets a completely unknown vendor. One could argue that KVM
should treat such vCPUs as not being compatible with Intel *or* AMD, but
that would add useless complexity to KVM.
KVM needs to do *something* in the face of vendor specific behavior, and
so unless KVM conjured up a magic third option, choosing to treat unknown
vendors as neither Intel nor AMD means that checks on AMD compatibility
would yield Intel behavior, and checks for Intel compatibility would yield
AMD behavior. And that's far worse as it would effectively yield random
behavior depending on whether KVM checked for AMD vs. Intel vs. !AMD vs.
!Intel. And practically speaking, all x86 CPUs follow either Intel or AMD
architecture, i.e. "supporting" an unknown third architecture adds no
value.
Deliberately don't convert any of the existing guest_cpuid_is_intel()
checks, as the Intel side of things is messier due to some flows explicitly
checking for exactly vendor==Intel, versus some flows assuming anything
that isn't "AMD compatible" gets Intel behavior. The Intel code will be
cleaned up in the future.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20240405235603.1173076-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-04-05 16:55:54 -07:00
|
|
|
vcpu->arch.is_amd_compatible = guest_cpuid_is_amd_or_hygon(vcpu);
|
2015-03-29 23:56:12 +03:00
|
|
|
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
|
2021-02-03 16:01:15 -08:00
|
|
|
vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu);
|
2015-03-29 23:56:12 +03:00
|
|
|
|
2015-06-19 13:44:45 +02:00
|
|
|
kvm_pmu_refresh(vcpu);
|
2020-09-29 21:16:56 -07:00
|
|
|
|
KVM: x86: Account for KVM-reserved CR4 bits when passing through CR4 on VMX
Drop x86.c's local pre-computed cr4_reserved bits and instead fold KVM's
reserved bits into the guest's reserved bits. This fixes a bug where VMX's
set_cr4_guest_host_mask() fails to account for KVM-reserved bits when
deciding which bits can be passed through to the guest. In most cases,
letting the guest directly write reserved CR4 bits is ok, i.e. attempting
to set the bit(s) will still #GP, but not if a feature is available in
hardware but explicitly disabled by the host, e.g. if FSGSBASE support is
disabled via "nofsgsbase".
Note, the extra overhead of computing host reserved bits every time
userspace sets guest CPUID is negligible. The feature bits that are
queried are packed nicely into a handful of words, and so checking and
setting each reserved bit costs in the neighborhood of ~5 cycles, i.e. the
total cost will be in the noise even if the number of checked CR4 bits
doubles over the next few years. In other words, x86 will run out of CR4
bits long before the overhead becomes problematic.
Note #2, __cr4_reserved_bits() starts from CR4_RESERVED_BITS, which is
why the existing __kvm_cpu_cap_has() processing doesn't explicitly OR in
CR4_RESERVED_BITS (and why the new code doesn't do so either).
Fixes: 2ed41aa631fc ("KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault")
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:33:32 -08:00
|
|
|
#define __kvm_cpu_cap_has(UNUSED_, f) kvm_cpu_cap_has(f)
|
|
|
|
vcpu->arch.cr4_guest_rsvd_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_) |
|
KVM: x86: Replace (almost) all guest CPUID feature queries with cpu_caps
Switch all queries (except XSAVES) of guest features from guest CPUID to
guest capabilities, i.e. replace all calls to guest_cpuid_has() with calls
to guest_cpu_cap_has().
Keep guest_cpuid_has() around for XSAVES, but subsume its helper
guest_cpuid_get_register() and add a compile-time assertion to prevent
using guest_cpuid_has() for any other feature. Add yet another comment
for XSAVE to explain why KVM is allowed to query its raw guest CPUID.
Opportunistically drop the unused guest_cpuid_clear(), as there should be
no circumstance in which KVM needs to _clear_ a guest CPUID feature now
that everything is tracked via cpu_caps. E.g. KVM may need to _change_
a feature to emulate dynamic CPUID flags, but KVM should never need to
clear a feature in guest CPUID to prevent it from being used by the guest.
Delete the last remnants of the governed features framework, as the lone
holdout was vmx_adjust_secondary_exec_control()'s divergent behavior for
governed vs. ungoverned features.
Note, replacing guest_cpuid_has() checks with guest_cpu_cap_has() when
computing reserved CR4 bits is a nop when viewed as a whole, as KVM's
capabilities are already incorporated into the calculation, i.e. if a
feature is present in guest CPUID but unsupported by KVM, its CR4 bit
was already being marked as reserved, checking guest_cpu_cap_has() simply
double-stamps that it's a reserved bit.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-51-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:17 -08:00
|
|
|
__cr4_reserved_bits(guest_cpu_cap_has, vcpu);
|
KVM: x86: Account for KVM-reserved CR4 bits when passing through CR4 on VMX
Drop x86.c's local pre-computed cr4_reserved bits and instead fold KVM's
reserved bits into the guest's reserved bits. This fixes a bug where VMX's
set_cr4_guest_host_mask() fails to account for KVM-reserved bits when
deciding which bits can be passed through to the guest. In most cases,
letting the guest directly write reserved CR4 bits is ok, i.e. attempting
to set the bit(s) will still #GP, but not if a feature is available in
hardware but explicitly disabled by the host, e.g. if FSGSBASE support is
disabled via "nofsgsbase".
Note, the extra overhead of computing host reserved bits every time
userspace sets guest CPUID is negligible. The feature bits that are
queried are packed nicely into a handful of words, and so checking and
setting each reserved bit costs in the neighborhood of ~5 cycles, i.e. the
total cost will be in the noise even if the number of checked CR4 bits
doubles over the next few years. In other words, x86 will run out of CR4
bits long before the overhead becomes problematic.
Note #2, __cr4_reserved_bits() starts from CR4_RESERVED_BITS, which is
why the existing __kvm_cpu_cap_has() processing doesn't explicitly OR in
CR4_RESERVED_BITS (and why the new code doesn't do so either).
Fixes: 2ed41aa631fc ("KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault")
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:33:32 -08:00
|
|
|
#undef __kvm_cpu_cap_has
|
2020-09-29 21:16:56 -07:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
kvm_hv_set_cpuid(vcpu, kvm_cpuid_has_hyperv(vcpu));
|
2021-01-26 14:48:14 +01:00
|
|
|
|
2020-09-29 21:16:56 -07:00
|
|
|
/* Invoke the vendor callback only after the above state is updated. */
|
2024-05-07 21:31:02 +08:00
|
|
|
kvm_x86_call(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-03 16:01:13 -08: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 10:56:51 -07: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-03 16:01:13 -08: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 10:56:51 -07:00
|
|
|
kvm_mmu_after_set_cpuid(vcpu);
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
2015-03-29 23:56:12 +03:00
|
|
|
int cpuid_query_maxphyaddr(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
2022-07-12 02:06:45 +02:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000000);
|
2015-03-29 23:56:12 +03:00
|
|
|
if (!best || best->eax < 0x80000008)
|
|
|
|
goto not_found;
|
2022-07-12 02:06:45 +02:00
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000008);
|
2015-03-29 23:56:12 +03:00
|
|
|
if (best)
|
|
|
|
return best->eax & 0xff;
|
|
|
|
not_found:
|
|
|
|
return 36;
|
|
|
|
}
|
|
|
|
|
2024-10-30 12:00:38 -07:00
|
|
|
int cpuid_query_maxguestphyaddr(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct kvm_cpuid_entry2 *best;
|
|
|
|
|
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000000);
|
|
|
|
if (!best || best->eax < 0x80000008)
|
|
|
|
goto not_found;
|
|
|
|
best = kvm_find_cpuid_entry(vcpu, 0x80000008);
|
|
|
|
if (best)
|
|
|
|
return (best->eax >> 16) & 0xff;
|
|
|
|
not_found:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-02-03 16:01:15 -08: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)
|
|
|
|
{
|
2024-11-27 17:34:07 -08:00
|
|
|
u32 vcpu_caps[NR_KVM_CPU_CAPS];
|
2022-01-05 04:35:19 -08:00
|
|
|
int r;
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
/*
|
|
|
|
* Swap the existing (old) entries with the incoming (new) entries in
|
|
|
|
* order to massage the new entries, e.g. to account for dynamic bits
|
|
|
|
* that KVM controls, without clobbering the current guest CPUID, which
|
|
|
|
* KVM needs to preserve in order to unwind on failure.
|
2024-11-27 17:34:07 -08:00
|
|
|
*
|
|
|
|
* Similarly, save the vCPU's current cpu_caps so that the capabilities
|
|
|
|
* can be updated alongside the CPUID entries when performing runtime
|
|
|
|
* updates. Full initialization is done if and only if the vCPU hasn't
|
|
|
|
* run, i.e. only if userspace is potentially changing CPUID features.
|
2024-11-27 17:33:58 -08:00
|
|
|
*/
|
|
|
|
swap(vcpu->arch.cpuid_entries, e2);
|
|
|
|
swap(vcpu->arch.cpuid_nent, nent);
|
|
|
|
|
2024-11-27 17:34:07 -08:00
|
|
|
memcpy(vcpu_caps, vcpu->arch.cpu_caps, sizeof(vcpu_caps));
|
|
|
|
BUILD_BUG_ON(sizeof(vcpu_caps) != sizeof(vcpu->arch.cpu_caps));
|
2022-01-17 16:05:39 +01:00
|
|
|
|
2022-01-17 16:05:40 +01: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.
|
|
|
|
*/
|
2023-03-10 16:45:59 -08:00
|
|
|
if (kvm_vcpu_has_run(vcpu)) {
|
2022-01-25 21:04:45 +00:00
|
|
|
r = kvm_cpuid_check_equal(vcpu, e2, nent);
|
|
|
|
if (r)
|
2024-11-27 17:33:58 -08:00
|
|
|
goto err;
|
|
|
|
goto success;
|
2022-01-25 21:04:45 +00:00
|
|
|
}
|
2022-01-17 16:05:40 +01:00
|
|
|
|
2023-12-05 11:36:26 +01:00
|
|
|
#ifdef CONFIG_KVM_HYPERV
|
2024-11-27 17:33:58 -08:00
|
|
|
if (kvm_cpuid_has_hyperv(vcpu)) {
|
2022-08-30 15:37:09 +02:00
|
|
|
r = kvm_hv_vcpu_init(vcpu);
|
|
|
|
if (r)
|
2024-11-27 17:33:58 -08:00
|
|
|
goto err;
|
2022-08-30 15:37:09 +02:00
|
|
|
}
|
2023-12-05 11:36:26 +01:00
|
|
|
#endif
|
2022-08-30 15:37:09 +02:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
r = kvm_check_cpuid(vcpu);
|
2022-01-05 04:35:19 -08:00
|
|
|
if (r)
|
2024-11-27 17:33:58 -08:00
|
|
|
goto err;
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2023-09-05 09:07:09 +08:00
|
|
|
#ifdef CONFIG_KVM_XEN
|
2023-01-06 10:36:00 +00:00
|
|
|
vcpu->arch.xen.cpuid = kvm_get_hypervisor_cpuid(vcpu, XEN_SIGNATURE);
|
2023-09-05 09:07:09 +08:00
|
|
|
#endif
|
2022-01-05 04:35:19 -08:00
|
|
|
kvm_vcpu_after_set_cpuid(vcpu);
|
2021-11-05 09:51:00 +00:00
|
|
|
|
2024-11-27 17:33:58 -08:00
|
|
|
success:
|
|
|
|
kvfree(e2);
|
2022-01-05 04:35:19 -08:00
|
|
|
return 0;
|
2024-11-27 17:33:58 -08:00
|
|
|
|
|
|
|
err:
|
2024-11-27 17:34:07 -08:00
|
|
|
memcpy(vcpu->arch.cpu_caps, vcpu_caps, sizeof(vcpu_caps));
|
2024-11-27 17:33:58 -08:00
|
|
|
swap(vcpu->arch.cpuid_entries, e2);
|
|
|
|
swap(vcpu->arch.cpuid_nent, nent);
|
|
|
|
return r;
|
2021-11-05 09:51:00 +00:00
|
|
|
}
|
|
|
|
|
2011-11-23 16:30:32 +02: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 15:05:40 +02:00
|
|
|
struct kvm_cpuid_entry *e = NULL;
|
|
|
|
struct kvm_cpuid_entry2 *e2 = NULL;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
2020-10-01 15:05:40 +02:00
|
|
|
return -E2BIG;
|
|
|
|
|
2016-06-01 14:09:19 +02:00
|
|
|
if (cpuid->nent) {
|
2023-11-02 19:15:24 +01:00
|
|
|
e = vmemdup_array_user(entries, cpuid->nent, sizeof(*e));
|
2020-10-01 15:05:40 +02:00
|
|
|
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 13:11:31 +03:00
|
|
|
}
|
2016-06-01 14:09:19 +02:00
|
|
|
}
|
2011-11-23 16:30:32 +02:00
|
|
|
for (i = 0; i < cpuid->nent; i++) {
|
2020-10-01 15:05:40 +02: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 16:30:32 +02:00
|
|
|
}
|
2020-10-01 15:05:40 +02:00
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
r = kvm_set_cpuid(vcpu, e2, cpuid->nent);
|
|
|
|
if (r)
|
2020-10-01 15:05:40 +02:00
|
|
|
kvfree(e2);
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2020-10-01 15:05:40 +02:00
|
|
|
out_free_cpuid:
|
|
|
|
kvfree(e);
|
|
|
|
|
2011-11-23 16:30:32 +02: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 15:05:40 +02:00
|
|
|
struct kvm_cpuid_entry2 *e2 = NULL;
|
2011-11-23 16:30:32 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
2020-10-01 15:05:40 +02:00
|
|
|
return -E2BIG;
|
|
|
|
|
|
|
|
if (cpuid->nent) {
|
2023-11-02 19:15:24 +01:00
|
|
|
e2 = vmemdup_array_user(entries, cpuid->nent, sizeof(*e2));
|
2020-10-01 15:05:40 +02:00
|
|
|
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 15:05:40 +02:00
|
|
|
kvfree(e2);
|
|
|
|
|
2021-11-05 09:51:00 +00:00
|
|
|
return r;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_vcpu_ioctl_get_cpuid2(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_cpuid2 *cpuid,
|
|
|
|
struct kvm_cpuid_entry2 __user *entries)
|
|
|
|
{
|
|
|
|
if (cpuid->nent < vcpu->arch.cpuid_nent)
|
2023-05-26 14:03:39 -07:00
|
|
|
return -E2BIG;
|
|
|
|
|
KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation
Defer runtime CPUID updates until the next non-faulting CPUID emulation
or KVM_GET_CPUID2, which are the only paths in KVM that consume the
dynamic entries. Deferring the updates is especially beneficial to
nested VM-Enter/VM-Exit, as KVM will almost always detect multiple state
changes, not to mention the updates don't need to be realized while L2 is
active if CPUID is being intercepted by L1 (CPUID is a mandatory intercept
on Intel, but not AMD).
Deferring CPUID updates shaves several hundred cycles from nested VMX
roundtrips, as measured from L2 executing CPUID in a tight loop:
SKX 6850 => 6450
ICX 9000 => 8800
EMR 7900 => 7700
Alternatively, KVM could update only the CPUID leaves that are affected
by the state change, e.g. update XSAVE info only if XCR0 or XSS changes,
but that adds non-trivial complexity and doesn't solve the underlying
problem of nested transitions potentially changing both XCR0 and XSS, on
both nested VM-Enter and VM-Exit.
Skipping updates entirely if L2 is active and CPUID is being intercepted
by L1 could work for the common case. However, simply skipping updates if
L2 is active is *very* subtly dangerous and complex. Most KVM updates are
triggered by changes to the current vCPU state, which may be L2 state,
whereas performing updates only for L1 would requiring detecting changes
to L1 state. KVM would need to either track relevant L1 state, or defer
runtime CPUID updates until the next nested VM-Exit. The former is ugly
and complex, while the latter comes with similar dangers to deferring all
CPUID updates, and would only address the nested VM-Enter path.
To guard against using stale data, disallow querying dynamic CPUID feature
bits, i.e. features that KVM updates at runtime, via a compile-time
assertion in guest_cpu_cap_has(). Exempt MWAIT from the rule, as the
MISC_ENABLE_NO_MWAIT means that MWAIT is _conditionally_ a dynamic CPUID
feature.
Note, the rule could be enforced for MWAIT as well, e.g. by querying guest
CPUID in kvm_emulate_monitor_mwait, but there's no obvious advtantage to
doing so, and allowing MWAIT for guest_cpuid_has() opens up a different can
of worms. MONITOR/MWAIT can't be virtualized (for a reasonable definition),
and the nature of the MWAIT_NEVER_UD_FAULTS and MISC_ENABLE_NO_MWAIT quirks
means checking X86_FEATURE_MWAIT outside of kvm_emulate_monitor_mwait() is
wrong for other reasons.
Beyond the aforementioned feature bits, the only other dynamic CPUID
(sub)leaves are the XSAVE sizes, and similar to MWAIT, consuming those
CPUID entries in KVM is all but guaranteed to be a bug. The layout for an
actual XSAVE buffer depends on the format (compacted or not) and
potentially the features that are actually enabled. E.g. see the logic in
fpstate_clear_xstate_component() needed to poke into the guest's effective
XSAVE state to clear MPX state on INIT. KVM does consume
CPUID.0xD.0.{EAX,EDX} in kvm_check_cpuid() and cpuid_get_supported_xcr0(),
but not EBX, which is the only dynamic output register in the leaf.
Link: https://lore.kernel.org/r/20241211013302.1347853-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-12-10 17:33:02 -08:00
|
|
|
if (vcpu->arch.cpuid_dynamic_bits_dirty)
|
|
|
|
kvm_update_cpuid_runtime(vcpu);
|
|
|
|
|
2021-01-27 20:44:51 -06:00
|
|
|
if (copy_to_user(entries, vcpu->arch.cpuid_entries,
|
2011-11-23 16:30:32 +02:00
|
|
|
vcpu->arch.cpuid_nent * sizeof(struct kvm_cpuid_entry2)))
|
2023-05-26 14:03:39 -07:00
|
|
|
return -EFAULT;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
cpuid->nent = vcpu->arch.cpuid_nent;
|
2023-05-26 14:03:39 -07:00
|
|
|
return 0;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
2024-11-27 17:33:48 -08:00
|
|
|
static __always_inline u32 raw_cpuid_get(struct cpuid_reg cpuid)
|
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 15:56:41 -08:00
|
|
|
{
|
2020-03-02 15:56:52 -08:00
|
|
|
struct kvm_cpuid_entry2 entry;
|
2024-11-27 17:33:48 -08:00
|
|
|
u32 base;
|
2020-03-02 15:56:52 -08:00
|
|
|
|
2024-11-27 17:33:48 -08:00
|
|
|
/*
|
|
|
|
* KVM only supports features defined by Intel (0x0), AMD (0x80000000),
|
|
|
|
* and Centaur (0xc0000000). WARN if a feature for new vendor base is
|
|
|
|
* defined, as this and other code would need to be updated.
|
|
|
|
*/
|
|
|
|
base = cpuid.function & 0xffff0000;
|
|
|
|
if (WARN_ON_ONCE(base && base != 0x80000000 && base != 0xc0000000))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (cpuid_eax(base) < cpuid.function)
|
|
|
|
return 0;
|
2020-03-02 15:56:52 -08:00
|
|
|
|
|
|
|
cpuid_count(cpuid.function, cpuid.index,
|
|
|
|
&entry.eax, &entry.ebx, &entry.ecx, &entry.edx);
|
|
|
|
|
2024-11-27 17:33:48 -08:00
|
|
|
return *__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 15:56:41 -08:00
|
|
|
}
|
|
|
|
|
2024-11-27 17:33:55 -08:00
|
|
|
/*
|
2024-11-27 17:34:20 -08:00
|
|
|
* For kernel-defined leafs, mask KVM's supported feature set with the kernel's
|
|
|
|
* capabilities as well as raw CPUID. For KVM-defined leafs, consult only raw
|
|
|
|
* CPUID, as KVM is the one and only authority (in the kernel).
|
2024-11-27 17:33:55 -08:00
|
|
|
*/
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
#define kvm_cpu_cap_init(leaf, feature_initializers...) \
|
2024-11-27 17:33:55 -08:00
|
|
|
do { \
|
|
|
|
const struct cpuid_reg cpuid = x86_feature_cpuid(leaf * 32); \
|
|
|
|
const u32 __maybe_unused kvm_cpu_cap_init_in_progress = leaf; \
|
2024-11-27 17:34:20 -08:00
|
|
|
const u32 *kernel_cpu_caps = boot_cpu_data.x86_capability; \
|
2024-11-27 17:33:56 -08:00
|
|
|
u32 kvm_cpu_cap_passthrough = 0; \
|
2024-11-27 17:34:19 -08:00
|
|
|
u32 kvm_cpu_cap_synthesized = 0; \
|
2024-11-27 17:33:57 -08:00
|
|
|
u32 kvm_cpu_cap_emulated = 0; \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
u32 kvm_cpu_cap_features = 0; \
|
2024-11-27 17:33:55 -08:00
|
|
|
\
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
feature_initializers \
|
|
|
|
\
|
|
|
|
kvm_cpu_caps[leaf] = kvm_cpu_cap_features; \
|
2024-11-27 17:34:20 -08:00
|
|
|
\
|
2024-11-27 17:33:55 -08:00
|
|
|
if (leaf < NCAPINTS) \
|
2024-11-27 17:34:20 -08:00
|
|
|
kvm_cpu_caps[leaf] &= kernel_cpu_caps[leaf]; \
|
2024-11-27 17:33:55 -08:00
|
|
|
\
|
2024-11-27 17:33:56 -08:00
|
|
|
kvm_cpu_caps[leaf] |= kvm_cpu_cap_passthrough; \
|
2024-11-27 17:34:19 -08:00
|
|
|
kvm_cpu_caps[leaf] &= (raw_cpuid_get(cpuid) | \
|
|
|
|
kvm_cpu_cap_synthesized); \
|
2024-11-27 17:33:57 -08:00
|
|
|
kvm_cpu_caps[leaf] |= kvm_cpu_cap_emulated; \
|
2024-11-27 17:33:55 -08:00
|
|
|
} while (0)
|
2021-04-12 16:21:35 +12:00
|
|
|
|
2024-11-27 17:33:55 -08:00
|
|
|
/*
|
|
|
|
* Assert that the feature bit being declared, e.g. via F(), is in the CPUID
|
|
|
|
* word that's being initialized. Exempt 0x8000_0001.EDX usage of 0x1.EDX
|
|
|
|
* features, as AMD duplicated many 0x1.EDX features into 0x8000_0001.EDX.
|
|
|
|
*/
|
|
|
|
#define KVM_VALIDATE_CPU_CAP_USAGE(name) \
|
|
|
|
do { \
|
|
|
|
u32 __leaf = __feature_leaf(X86_FEATURE_##name); \
|
|
|
|
\
|
|
|
|
BUILD_BUG_ON(__leaf != kvm_cpu_cap_init_in_progress); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#define F(name) \
|
|
|
|
({ \
|
|
|
|
KVM_VALIDATE_CPU_CAP_USAGE(name); \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
kvm_cpu_cap_features |= feature_bit(name); \
|
2024-11-27 17:33:55 -08:00
|
|
|
})
|
2021-04-12 16:21:35 +12:00
|
|
|
|
2024-11-27 17:33:29 -08:00
|
|
|
/* Scattered Flag - For features that are scattered by cpufeatures.h. */
|
2024-11-27 17:34:21 -08:00
|
|
|
#define SCATTERED_F(name) \
|
2024-11-27 17:33:29 -08:00
|
|
|
({ \
|
|
|
|
BUILD_BUG_ON(X86_FEATURE_##name >= MAX_CPU_FEATURES); \
|
2024-11-27 17:33:55 -08:00
|
|
|
KVM_VALIDATE_CPU_CAP_USAGE(name); \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
if (boot_cpu_has(X86_FEATURE_##name)) \
|
|
|
|
F(name); \
|
2024-11-27 17:33:29 -08:00
|
|
|
})
|
2021-04-12 16:21:35 +12:00
|
|
|
|
2024-11-27 17:33:51 -08:00
|
|
|
/* Features that KVM supports only on 64-bit kernels. */
|
|
|
|
#define X86_64_F(name) \
|
|
|
|
({ \
|
2024-11-27 17:33:55 -08:00
|
|
|
KVM_VALIDATE_CPU_CAP_USAGE(name); \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
if (IS_ENABLED(CONFIG_X86_64)) \
|
|
|
|
F(name); \
|
2024-11-27 17:33:51 -08:00
|
|
|
})
|
2021-04-12 16:21:35 +12:00
|
|
|
|
2024-11-27 17:33:57 -08:00
|
|
|
/*
|
|
|
|
* Emulated Feature - For features that KVM emulates in software irrespective
|
|
|
|
* of host CPU/kernel support.
|
|
|
|
*/
|
|
|
|
#define EMULATED_F(name) \
|
|
|
|
({ \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
kvm_cpu_cap_emulated |= feature_bit(name); \
|
2024-11-27 17:33:57 -08:00
|
|
|
F(name); \
|
|
|
|
})
|
2021-04-12 16:21:35 +12:00
|
|
|
|
2024-11-27 17:34:19 -08:00
|
|
|
/*
|
|
|
|
* Synthesized Feature - For features that are synthesized into boot_cpu_data,
|
|
|
|
* i.e. may not be present in the raw CPUID, but can still be advertised to
|
|
|
|
* userspace. Primarily used for mitigation related feature flags.
|
|
|
|
*/
|
|
|
|
#define SYNTHESIZED_F(name) \
|
|
|
|
({ \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
kvm_cpu_cap_synthesized |= feature_bit(name); \
|
2024-11-27 17:34:19 -08:00
|
|
|
F(name); \
|
|
|
|
})
|
|
|
|
|
2024-11-27 17:33:56 -08:00
|
|
|
/*
|
|
|
|
* Passthrough Feature - For features that KVM supports based purely on raw
|
|
|
|
* hardware CPUID, i.e. that KVM virtualizes even if the host kernel doesn't
|
|
|
|
* use the feature. Simply force set the feature in KVM's capabilities, raw
|
|
|
|
* CPUID support will be factored in by kvm_cpu_cap_mask().
|
|
|
|
*/
|
|
|
|
#define PASSTHROUGH_F(name) \
|
|
|
|
({ \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
kvm_cpu_cap_passthrough |= feature_bit(name); \
|
2024-11-27 17:33:56 -08:00
|
|
|
F(name); \
|
|
|
|
})
|
|
|
|
|
2024-11-27 17:33:52 -08:00
|
|
|
/*
|
|
|
|
* Aliased Features - For features in 0x8000_0001.EDX that are duplicates of
|
|
|
|
* identical 0x1.EDX features, and thus are aliased from 0x1 to 0x8000_0001.
|
|
|
|
*/
|
|
|
|
#define ALIASED_1_EDX_F(name) \
|
|
|
|
({ \
|
|
|
|
BUILD_BUG_ON(__feature_leaf(X86_FEATURE_##name) != CPUID_1_EDX); \
|
2024-11-27 17:33:55 -08:00
|
|
|
BUILD_BUG_ON(kvm_cpu_cap_init_in_progress != CPUID_8000_0001_EDX); \
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
kvm_cpu_cap_features |= feature_bit(name); \
|
2024-11-27 17:33:52 -08:00
|
|
|
})
|
|
|
|
|
KVM: x86: Explicitly track feature flags that require vendor enabling
Add another CPUID feature macro, VENDOR_F(), and use it to track features
that KVM supports, but that need additional vendor support and so are
conditionally enabled in vendor code.
Currently, VENDOR_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
To fudge around a macro collision on 32-bit kernels, #undef DS to be able
to get at X86_FEATURE_DS.
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-56-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:22 -08:00
|
|
|
/*
|
|
|
|
* Vendor Features - For features that KVM supports, but are added in later
|
|
|
|
* because they require additional vendor enabling.
|
|
|
|
*/
|
|
|
|
#define VENDOR_F(name) \
|
|
|
|
({ \
|
|
|
|
KVM_VALIDATE_CPU_CAP_USAGE(name); \
|
|
|
|
})
|
|
|
|
|
KVM: x86: Explicitly track feature flags that are enabled at runtime
Add one last (hopefully) CPUID feature macro, RUNTIME_F(), and use it
to track features that KVM supports, but that are only set at runtime
(in response to other state), and aren't advertised to userspace via
KVM_GET_SUPPORTED_CPUID.
Currently, RUNTIME_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-57-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:23 -08:00
|
|
|
/*
|
|
|
|
* Runtime Features - For features that KVM dynamically sets/clears at runtime,
|
|
|
|
* e.g. when CR4 changes, but which are never advertised to userspace.
|
|
|
|
*/
|
|
|
|
#define RUNTIME_F(name) \
|
|
|
|
({ \
|
|
|
|
KVM_VALIDATE_CPU_CAP_USAGE(name); \
|
|
|
|
})
|
|
|
|
|
2024-11-27 17:33:54 -08:00
|
|
|
/*
|
|
|
|
* Undefine the MSR bit macro to avoid token concatenation issues when
|
|
|
|
* processing X86_FEATURE_SPEC_CTRL_SSBD.
|
|
|
|
*/
|
|
|
|
#undef SPEC_CTRL_SSBD
|
|
|
|
|
KVM: x86: Explicitly track feature flags that require vendor enabling
Add another CPUID feature macro, VENDOR_F(), and use it to track features
that KVM supports, but that need additional vendor support and so are
conditionally enabled in vendor code.
Currently, VENDOR_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
To fudge around a macro collision on 32-bit kernels, #undef DS to be able
to get at X86_FEATURE_DS.
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-56-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:22 -08:00
|
|
|
/* DS is defined by ptrace-abi.h on 32-bit builds. */
|
|
|
|
#undef DS
|
2021-04-12 16:21:35 +12: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 15:56:41 -08:00
|
|
|
void kvm_set_cpu_caps(void)
|
|
|
|
{
|
2021-04-12 16:21:35 +12: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 15:56:41 -08:00
|
|
|
|
2021-04-12 16:21:35 +12: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 15:56:41 -08:00
|
|
|
sizeof(boot_cpu_data.x86_capability));
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_1_ECX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(XMM3),
|
|
|
|
F(PCLMULQDQ),
|
|
|
|
VENDOR_F(DTES64),
|
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 15:56:41 -08:00
|
|
|
/*
|
|
|
|
* NOTE: MONITOR (and MWAIT) are emulated as NOP, but *not*
|
KVM: x86: Explicitly track feature flags that are enabled at runtime
Add one last (hopefully) CPUID feature macro, RUNTIME_F(), and use it
to track features that KVM supports, but that are only set at runtime
(in response to other state), and aren't advertised to userspace via
KVM_GET_SUPPORTED_CPUID.
Currently, RUNTIME_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-57-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:23 -08:00
|
|
|
* advertised to guests via CPUID! MWAIT is also technically a
|
|
|
|
* runtime flag thanks to IA32_MISC_ENABLES; mark it as such so
|
|
|
|
* that KVM is aware that it's a known, unadvertised flag.
|
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 15:56:41 -08:00
|
|
|
*/
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
RUNTIME_F(MWAIT),
|
|
|
|
/* DS-CPL */
|
|
|
|
VENDOR_F(VMX),
|
|
|
|
/* SMX, EST */
|
|
|
|
/* TM2 */
|
|
|
|
F(SSSE3),
|
|
|
|
/* CNXT-ID */
|
|
|
|
/* Reserved */
|
|
|
|
F(FMA),
|
|
|
|
F(CX16),
|
|
|
|
/* xTPR Update */
|
|
|
|
F(PDCM),
|
|
|
|
F(PCID),
|
|
|
|
/* Reserved, DCA */
|
|
|
|
F(XMM4_1),
|
|
|
|
F(XMM4_2),
|
|
|
|
EMULATED_F(X2APIC),
|
|
|
|
F(MOVBE),
|
|
|
|
F(POPCNT),
|
|
|
|
EMULATED_F(TSC_DEADLINE_TIMER),
|
|
|
|
F(AES),
|
|
|
|
F(XSAVE),
|
|
|
|
RUNTIME_F(OSXSAVE),
|
|
|
|
F(AVX),
|
|
|
|
F(F16C),
|
|
|
|
F(RDRAND),
|
|
|
|
EMULATED_F(HYPERVISOR),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_1_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(FPU),
|
|
|
|
F(VME),
|
|
|
|
F(DE),
|
|
|
|
F(PSE),
|
|
|
|
F(TSC),
|
|
|
|
F(MSR),
|
|
|
|
F(PAE),
|
|
|
|
F(MCE),
|
|
|
|
F(CX8),
|
|
|
|
F(APIC),
|
|
|
|
/* Reserved */
|
|
|
|
F(SEP),
|
|
|
|
F(MTRR),
|
|
|
|
F(PGE),
|
|
|
|
F(MCA),
|
|
|
|
F(CMOV),
|
|
|
|
F(PAT),
|
|
|
|
F(PSE36),
|
|
|
|
/* PSN */
|
|
|
|
F(CLFLUSH),
|
|
|
|
/* Reserved */
|
|
|
|
VENDOR_F(DS),
|
|
|
|
/* ACPI */
|
|
|
|
F(MMX),
|
|
|
|
F(FXSR),
|
|
|
|
F(XMM),
|
|
|
|
F(XMM2),
|
|
|
|
F(SELFSNOOP),
|
|
|
|
/* HTT, TM, Reserved, PBE */
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_0_EBX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(FSGSBASE),
|
|
|
|
EMULATED_F(TSC_ADJUST),
|
|
|
|
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),
|
|
|
|
VENDOR_F(MPX),
|
|
|
|
F(AVX512F),
|
|
|
|
F(AVX512DQ),
|
|
|
|
F(RDSEED),
|
|
|
|
F(ADX),
|
|
|
|
F(SMAP),
|
|
|
|
F(AVX512IFMA),
|
|
|
|
F(CLFLUSHOPT),
|
|
|
|
F(CLWB),
|
|
|
|
VENDOR_F(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 15:56:41 -08:00
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_ECX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AVX512VBMI),
|
|
|
|
PASSTHROUGH_F(LA57),
|
|
|
|
F(PKU),
|
|
|
|
RUNTIME_F(OSPKE),
|
|
|
|
F(RDPID),
|
|
|
|
F(AVX512_VPOPCNTDQ),
|
|
|
|
F(UMIP),
|
|
|
|
F(AVX512_VBMI2),
|
|
|
|
F(GFNI),
|
|
|
|
F(VAES),
|
|
|
|
F(VPCLMULQDQ),
|
|
|
|
F(AVX512_VNNI),
|
|
|
|
F(AVX512_BITALG),
|
|
|
|
F(CLDEMOTE),
|
|
|
|
F(MOVDIRI),
|
|
|
|
F(MOVDIR64B),
|
|
|
|
VENDOR_F(WAITPKG),
|
|
|
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2020-05-12 18:59:16 -05: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);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AVX512_4VNNIW),
|
|
|
|
F(AVX512_4FMAPS),
|
|
|
|
F(SPEC_CTRL),
|
|
|
|
F(SPEC_CTRL_SSBD),
|
|
|
|
EMULATED_F(ARCH_CAPABILITIES),
|
|
|
|
F(INTEL_STIBP),
|
|
|
|
F(MD_CLEAR),
|
|
|
|
F(AVX512_VP2INTERSECT),
|
|
|
|
F(FSRM),
|
|
|
|
F(SERIALIZE),
|
|
|
|
F(TSXLDTRK),
|
|
|
|
F(AVX512_FP16),
|
|
|
|
F(AMX_TILE),
|
|
|
|
F(AMX_INT8),
|
|
|
|
F(AMX_BF16),
|
|
|
|
F(FLUSH_L1D),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
KVM: x86: AMD's IBPB is not equivalent to Intel's IBPB
From Intel's documentation [1], "CPUID.(EAX=07H,ECX=0):EDX[26]
enumerates support for indirect branch restricted speculation (IBRS)
and the indirect branch predictor barrier (IBPB)." Further, from [2],
"Software that executed before the IBPB command cannot control the
predicted targets of indirect branches (4) executed after the command
on the same logical processor," where footnote 4 reads, "Note that
indirect branches include near call indirect, near jump indirect and
near return instructions. Because it includes near returns, it follows
that **RSB entries created before an IBPB command cannot control the
predicted targets of returns executed after the command on the same
logical processor.**" [emphasis mine]
On the other hand, AMD's IBPB "may not prevent return branch
predictions from being specified by pre-IBPB branch targets" [3].
However, some AMD processors have an "enhanced IBPB" [terminology
mine] which does clear the return address predictor. This feature is
enumerated by CPUID.80000008:EDX.IBPB_RET[bit 30] [4].
Adjust the cross-vendor features enumerated by KVM_GET_SUPPORTED_CPUID
accordingly.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
[2] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/speculative-execution-side-channel-mitigations.html#Footnotes
[3] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html
[4] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf
Fixes: 0c54914d0c52 ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code")
Suggested-by: Venkatesh Srinivas <venkateshs@chromium.org>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20241011214353.1625057-5-jmattson@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-10-11 14:43:53 -07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_AMD_IBPB_RET) &&
|
|
|
|
boot_cpu_has(X86_FEATURE_AMD_IBPB) &&
|
|
|
|
boot_cpu_has(X86_FEATURE_AMD_IBRS))
|
2020-03-02 15:56:54 -08:00
|
|
|
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);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_1_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(SHA512),
|
|
|
|
F(SM3),
|
|
|
|
F(SM4),
|
|
|
|
F(AVX_VNNI),
|
|
|
|
F(AVX512_BF16),
|
|
|
|
F(CMPCCXADD),
|
|
|
|
F(FZRM),
|
|
|
|
F(FSRS),
|
|
|
|
F(FSRC),
|
2025-02-26 17:01:11 -08:00
|
|
|
F(WRMSRNS),
|
2025-06-26 10:35:21 -07:00
|
|
|
X86_64_F(LKGS),
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AMX_FP16),
|
|
|
|
F(AVX_IFMA),
|
|
|
|
F(LAM),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_1_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AVX_VNNI_INT8),
|
|
|
|
F(AVX_NE_CONVERT),
|
|
|
|
F(AMX_COMPLEX),
|
|
|
|
F(AVX_VNNI_INT16),
|
|
|
|
F(PREFETCHITI),
|
|
|
|
F(AVX10),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_7_2_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(INTEL_PSFD),
|
|
|
|
F(IPRED_CTRL),
|
|
|
|
F(RRSBA_CTRL),
|
|
|
|
F(DDPD_U),
|
|
|
|
F(BHI_CTRL),
|
|
|
|
F(MCDT_NO),
|
2023-10-23 17:16:35 -07:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_D_1_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(XSAVEOPT),
|
|
|
|
F(XSAVEC),
|
|
|
|
F(XGETBV1),
|
|
|
|
F(XSAVES),
|
|
|
|
X86_64_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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_12_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
SCATTERED_F(SGX1),
|
|
|
|
SCATTERED_F(SGX2),
|
|
|
|
SCATTERED_F(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 16:21:42 +12:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_24_0_EBX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AVX10_128),
|
|
|
|
F(AVX10_256),
|
|
|
|
F(AVX10_512),
|
KVM: x86: Advertise AVX10.1 CPUID to userspace
Advertise AVX10.1 related CPUIDs, i.e. report AVX10 support bit via
CPUID.(EAX=07H, ECX=01H):EDX[bit 19] and new CPUID leaf 0x24H so that
guest OS and applications can query the AVX10.1 CPUIDs directly. Intel
AVX10 represents the first major new vector ISA since the introduction of
Intel AVX512, which will establish a common, converged vector instruction
set across all Intel architectures[1].
AVX10.1 is an early version of AVX10, that enumerates the Intel AVX512
instruction set at 128, 256, and 512 bits which is enabled on
Granite Rapids. I.e., AVX10.1 is only a new CPUID enumeration with no
new functionality. New features, e.g. Embedded Rounding and Suppress
All Exceptions (SAE) will be introduced in AVX10.2.
Advertising AVX10.1 is safe because there is nothing to enable for AVX10.1,
i.e. it's purely a new way to enumerate support, thus there will never be
anything for the kernel to enable. Note just the CPUID checking is changed
when using AVX512 related instructions, e.g. if using one AVX512
instruction needs to check (AVX512 AND AVX512DQ), it can check
((AVX512 AND AVX512DQ) OR AVX10.1) after checking XCR0[7:5].
The versions of AVX10 are expected to be inclusive, e.g. version N+1 is
a superset of version N. Per the spec, the version can never be 0, just
advertise AVX10.1 if it's supported in hardware. Moreover, advertising
AVX10_{128,256,512} needs to land in the same commit as advertising basic
AVX10.1 support, otherwise KVM would advertise an impossible CPU model.
E.g. a CPU with AVX512 but not AVX10.1/512 is impossible per the SDM.
As more and more AVX related CPUIDs are added (it would have resulted in
around 40-50 CPUID flags when developing AVX10), the versioning approach
is introduced. But incrementing version numbers are bad for virtualization.
E.g. if AVX10.2 has a feature that shouldn't be enumerated to guests for
whatever reason, then KVM can't enumerate any "later" features either,
because the only way to hide the problematic AVX10.2 feature is to set the
version to AVX10.1 or lower[2]. But most AVX features are just passed
through and don't have virtualization controls, so AVX10 should not be
problematic in practice, so long as Intel honors their promise that future
versions will be supersets of past versions.
[1] https://cdrdv2.intel.com/v1/dl/getContent/784267
[2] https://lore.kernel.org/all/Zkz5Ak0PQlAN8DxK@google.com/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tao Su <tao1.su@linux.intel.com>
Link: https://lore.kernel.org/r/20240819062327.3269720-1-tao1.su@linux.intel.com
[sean: minor changelog tweaks]
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-19 14:23:27 +08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0001_ECX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(LAHF_LM),
|
|
|
|
F(CMP_LEGACY),
|
|
|
|
VENDOR_F(SVM),
|
|
|
|
/* ExtApicSpace */
|
|
|
|
F(CR8_LEGACY),
|
|
|
|
F(ABM),
|
|
|
|
F(SSE4A),
|
|
|
|
F(MISALIGNSSE),
|
|
|
|
F(3DNOWPREFETCH),
|
|
|
|
F(OSVW),
|
|
|
|
/* IBS */
|
|
|
|
F(XOP),
|
|
|
|
/* SKINIT, WDT, LWP */
|
|
|
|
F(FMA4),
|
|
|
|
F(TBM),
|
|
|
|
F(TOPOEXT),
|
|
|
|
VENDOR_F(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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0001_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
ALIASED_1_EDX_F(FPU),
|
|
|
|
ALIASED_1_EDX_F(VME),
|
|
|
|
ALIASED_1_EDX_F(DE),
|
|
|
|
ALIASED_1_EDX_F(PSE),
|
|
|
|
ALIASED_1_EDX_F(TSC),
|
|
|
|
ALIASED_1_EDX_F(MSR),
|
|
|
|
ALIASED_1_EDX_F(PAE),
|
|
|
|
ALIASED_1_EDX_F(MCE),
|
|
|
|
ALIASED_1_EDX_F(CX8),
|
|
|
|
ALIASED_1_EDX_F(APIC),
|
|
|
|
/* Reserved */
|
|
|
|
F(SYSCALL),
|
|
|
|
ALIASED_1_EDX_F(MTRR),
|
|
|
|
ALIASED_1_EDX_F(PGE),
|
|
|
|
ALIASED_1_EDX_F(MCA),
|
|
|
|
ALIASED_1_EDX_F(CMOV),
|
|
|
|
ALIASED_1_EDX_F(PAT),
|
|
|
|
ALIASED_1_EDX_F(PSE36),
|
|
|
|
/* Reserved */
|
|
|
|
F(NX),
|
|
|
|
/* Reserved */
|
|
|
|
F(MMXEXT),
|
|
|
|
ALIASED_1_EDX_F(MMX),
|
|
|
|
ALIASED_1_EDX_F(FXSR),
|
|
|
|
F(FXSR_OPT),
|
|
|
|
X86_64_F(GBPAGES),
|
|
|
|
F(RDTSCP),
|
|
|
|
/* Reserved */
|
|
|
|
X86_64_F(LM),
|
|
|
|
F(3DNOWEXT),
|
|
|
|
F(3DNOW),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
|
|
|
if (!tdp_enabled && IS_ENABLED(CONFIG_X86_64))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_GBPAGES);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0007_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
SCATTERED_F(CONSTANT_TSC),
|
2022-10-13 11:58:44 +02:00
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0008_EBX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(CLZERO),
|
|
|
|
F(XSAVEERPTR),
|
|
|
|
F(WBNOINVD),
|
|
|
|
F(AMD_IBPB),
|
|
|
|
F(AMD_IBRS),
|
|
|
|
F(AMD_SSBD),
|
|
|
|
F(VIRT_SSBD),
|
|
|
|
F(AMD_SSB_NO),
|
|
|
|
F(AMD_STIBP),
|
|
|
|
F(AMD_STIBP_ALWAYS_ON),
|
2025-02-21 16:33:51 +00:00
|
|
|
F(AMD_IBRS_SAME_MODE),
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AMD_PSFD),
|
|
|
|
F(AMD_IBPB_RET),
|
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 15:56:41 -08:00
|
|
|
);
|
|
|
|
|
2020-03-02 15:56:54 -08: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.
|
|
|
|
*/
|
KVM: x86: AMD's IBPB is not equivalent to Intel's IBPB
From Intel's documentation [1], "CPUID.(EAX=07H,ECX=0):EDX[26]
enumerates support for indirect branch restricted speculation (IBRS)
and the indirect branch predictor barrier (IBPB)." Further, from [2],
"Software that executed before the IBPB command cannot control the
predicted targets of indirect branches (4) executed after the command
on the same logical processor," where footnote 4 reads, "Note that
indirect branches include near call indirect, near jump indirect and
near return instructions. Because it includes near returns, it follows
that **RSB entries created before an IBPB command cannot control the
predicted targets of returns executed after the command on the same
logical processor.**" [emphasis mine]
On the other hand, AMD's IBPB "may not prevent return branch
predictions from being specified by pre-IBPB branch targets" [3].
However, some AMD processors have an "enhanced IBPB" [terminology
mine] which does clear the return address predictor. This feature is
enumerated by CPUID.80000008:EDX.IBPB_RET[bit 30] [4].
Adjust the cross-vendor features enumerated by KVM_GET_SUPPORTED_CPUID
accordingly.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
[2] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/speculative-execution-side-channel-mitigations.html#Footnotes
[3] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html
[4] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf
Fixes: 0c54914d0c52 ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code")
Suggested-by: Venkatesh Srinivas <venkateshs@chromium.org>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20241011214353.1625057-5-jmattson@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-10-11 14:43:53 -07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_IBPB)) {
|
2020-03-02 15:56:54 -08:00
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB);
|
KVM: x86: AMD's IBPB is not equivalent to Intel's IBPB
From Intel's documentation [1], "CPUID.(EAX=07H,ECX=0):EDX[26]
enumerates support for indirect branch restricted speculation (IBRS)
and the indirect branch predictor barrier (IBPB)." Further, from [2],
"Software that executed before the IBPB command cannot control the
predicted targets of indirect branches (4) executed after the command
on the same logical processor," where footnote 4 reads, "Note that
indirect branches include near call indirect, near jump indirect and
near return instructions. Because it includes near returns, it follows
that **RSB entries created before an IBPB command cannot control the
predicted targets of returns executed after the command on the same
logical processor.**" [emphasis mine]
On the other hand, AMD's IBPB "may not prevent return branch
predictions from being specified by pre-IBPB branch targets" [3].
However, some AMD processors have an "enhanced IBPB" [terminology
mine] which does clear the return address predictor. This feature is
enumerated by CPUID.80000008:EDX.IBPB_RET[bit 30] [4].
Adjust the cross-vendor features enumerated by KVM_GET_SUPPORTED_CPUID
accordingly.
[1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
[2] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/speculative-execution-side-channel-mitigations.html#Footnotes
[3] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1040.html
[4] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf
Fixes: 0c54914d0c52 ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code")
Suggested-by: Venkatesh Srinivas <venkateshs@chromium.org>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20241011214353.1625057-5-jmattson@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-10-11 14:43:53 -07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_SPEC_CTRL) &&
|
|
|
|
!boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB))
|
|
|
|
kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB_RET);
|
|
|
|
}
|
2020-03-02 15:56:54 -08:00
|
|
|
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);
|
|
|
|
|
KVM: x86: Explicitly track feature flags that require vendor enabling
Add another CPUID feature macro, VENDOR_F(), and use it to track features
that KVM supports, but that need additional vendor support and so are
conditionally enabled in vendor code.
Currently, VENDOR_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
To fudge around a macro collision on 32-bit kernels, #undef DS to be able
to get at X86_FEATURE_DS.
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-56-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:22 -08:00
|
|
|
/* All SVM features required additional vendor module enabling. */
|
|
|
|
kvm_cpu_cap_init(CPUID_8000_000A_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
VENDOR_F(NPT),
|
|
|
|
VENDOR_F(VMCBCLEAN),
|
|
|
|
VENDOR_F(FLUSHBYASID),
|
|
|
|
VENDOR_F(NRIPS),
|
|
|
|
VENDOR_F(TSCRATEMSR),
|
|
|
|
VENDOR_F(V_VMSAVE_VMLOAD),
|
|
|
|
VENDOR_F(LBRV),
|
|
|
|
VENDOR_F(PAUSEFILTER),
|
|
|
|
VENDOR_F(PFTHRESHOLD),
|
|
|
|
VENDOR_F(VGIF),
|
|
|
|
VENDOR_F(VNMI),
|
|
|
|
VENDOR_F(SVME_ADDR_CHK),
|
KVM: x86: Explicitly track feature flags that require vendor enabling
Add another CPUID feature macro, VENDOR_F(), and use it to track features
that KVM supports, but that need additional vendor support and so are
conditionally enabled in vendor code.
Currently, VENDOR_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
To fudge around a macro collision on 32-bit kernels, #undef DS to be able
to get at X86_FEATURE_DS.
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-56-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:22 -08:00
|
|
|
);
|
2021-04-21 19:11:15 -07:00
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_001F_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
VENDOR_F(SME),
|
|
|
|
VENDOR_F(SEV),
|
|
|
|
/* VM_PAGE_FLUSH */
|
|
|
|
VENDOR_F(SEV_ES),
|
|
|
|
F(SME_COHERENT),
|
2023-01-24 10:33:13 -06:00
|
|
|
);
|
2023-01-24 10:33:15 -06:00
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0021_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(NO_NESTED_DATA_BP),
|
2025-03-24 17:06:17 +01:00
|
|
|
F(WRMSR_XX_BASE_NS),
|
2024-11-27 17:34:19 -08:00
|
|
|
/*
|
|
|
|
* Synthesize "LFENCE is serializing" into the AMD-defined entry
|
|
|
|
* in KVM's supported CPUID, i.e. 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, ANDing with the raw host
|
|
|
|
* CPUID will drop the flags, and reporting support in AMD's
|
|
|
|
* leaf can make it easier for userspace to detect the feature.
|
|
|
|
*/
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
SYNTHESIZED_F(LFENCE_RDTSC),
|
|
|
|
/* SmmPgCfgLock */
|
2024-09-11 11:00:50 +02:00
|
|
|
/* 4: Resv */
|
|
|
|
SYNTHESIZED_F(VERW_CLEAR),
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(NULL_SEL_CLR_BASE),
|
2025-03-24 17:06:17 +01:00
|
|
|
/* UpperAddressIgnore */
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(AUTOIBRS),
|
2025-04-08 17:57:09 -05:00
|
|
|
F(PREFETCHI),
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
EMULATED_F(NO_SMM_CTL_MSR),
|
|
|
|
/* PrefetchCtlMsr */
|
2025-03-24 17:06:17 +01:00
|
|
|
/* GpOnUserCpuid */
|
|
|
|
/* EPSF */
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
SYNTHESIZED_F(SBPB),
|
|
|
|
SYNTHESIZED_F(IBPB_BRTYPE),
|
|
|
|
SYNTHESIZED_F(SRSO_NO),
|
2025-02-04 11:13:24 -05:00
|
|
|
F(SRSO_USER_KERNEL_NO),
|
2023-01-24 10:33:13 -06:00
|
|
|
);
|
2023-06-29 17:43:40 +02:00
|
|
|
|
2024-09-11 11:00:50 +02:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0021_ECX,
|
|
|
|
SYNTHESIZED_F(TSA_SQ_NO),
|
|
|
|
SYNTHESIZED_F(TSA_L1_NO),
|
|
|
|
);
|
|
|
|
|
2024-11-27 17:33:53 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_8000_0022_EAX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
F(PERFMON_V2),
|
2023-06-02 18:10:58 -07:00
|
|
|
);
|
|
|
|
|
2023-01-24 10:33:13 -06:00
|
|
|
if (!static_cpu_has_bug(X86_BUG_NULL_SEG))
|
2023-01-24 10:33:16 -06:00
|
|
|
kvm_cpu_cap_set(X86_FEATURE_NULL_SEL_CLR_BASE);
|
2023-01-24 10:33:13 -06:00
|
|
|
|
2024-11-27 17:33:50 -08:00
|
|
|
kvm_cpu_cap_init(CPUID_C000_0001_EDX,
|
KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps
Refactor the kvm_cpu_cap_init() macro magic to collect supported features
in a local variable instead of passing them to the macro as a "mask". As
pointed out by Maxim, relying on macros to "return" a value and set local
variables is surprising, as the bitwise-OR logic suggests the macros are
pure, i.e. have no side effects.
Ideally, the feature initializers would have zero side effects, e.g. would
take local variables as params, but there isn't a sane way to do so
without either sacrificing the various compile-time assertions (basically
a non-starter), or passing at least one variable, e.g. a struct, to each
macro usage (adds a lot of noise and boilerplate code).
Opportunistically force callers to emit a trailing comma by intentionally
omitting a semicolon after invoking the feature initializers. Forcing a
trailing comma isotales futures changes to a single line, i.e. doesn't
cause churn for unrelated features/lines when adding/removing/modifying a
feature.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-58-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:24 -08:00
|
|
|
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),
|
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 15:56:41 -08:00
|
|
|
);
|
2021-05-04 10:17:34 -07: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 15:56:41 -08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_set_cpu_caps);
|
|
|
|
|
2024-11-27 17:33:29 -08:00
|
|
|
#undef F
|
2024-11-27 17:34:21 -08:00
|
|
|
#undef SCATTERED_F
|
2024-11-27 17:33:51 -08:00
|
|
|
#undef X86_64_F
|
2024-11-27 17:33:57 -08:00
|
|
|
#undef EMULATED_F
|
2024-11-27 17:34:19 -08:00
|
|
|
#undef SYNTHESIZED_F
|
2024-11-27 17:33:56 -08:00
|
|
|
#undef PASSTHROUGH_F
|
2024-11-27 17:33:52 -08:00
|
|
|
#undef ALIASED_1_EDX_F
|
KVM: x86: Explicitly track feature flags that require vendor enabling
Add another CPUID feature macro, VENDOR_F(), and use it to track features
that KVM supports, but that need additional vendor support and so are
conditionally enabled in vendor code.
Currently, VENDOR_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
To fudge around a macro collision on 32-bit kernels, #undef DS to be able
to get at X86_FEATURE_DS.
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-56-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:22 -08:00
|
|
|
#undef VENDOR_F
|
KVM: x86: Explicitly track feature flags that are enabled at runtime
Add one last (hopefully) CPUID feature macro, RUNTIME_F(), and use it
to track features that KVM supports, but that are only set at runtime
(in response to other state), and aren't advertised to userspace via
KVM_GET_SUPPORTED_CPUID.
Currently, RUNTIME_F() is mostly just documentation, but tracking all
KVM-supported features will allow for asserting, at build time, take),
that all features that are set, cleared, *or* checked by KVM are known to
kvm_set_cpu_caps().
No functional change intended.
Link: https://lore.kernel.org/r/20241128013424.4096668-57-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:23 -08:00
|
|
|
#undef RUNTIME_F
|
2024-11-27 17:33:29 -08:00
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
struct kvm_cpuid_array {
|
|
|
|
struct kvm_cpuid_entry2 *entries;
|
2020-06-04 12:16:36 +08:00
|
|
|
int maxnent;
|
2020-03-02 15:56:19 -08:00
|
|
|
int nent;
|
|
|
|
};
|
|
|
|
|
2022-10-22 04:17:53 -04:00
|
|
|
static struct kvm_cpuid_entry2 *get_next_cpuid(struct kvm_cpuid_array *array)
|
|
|
|
{
|
|
|
|
if (array->nent >= array->maxnent)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return &array->entries[array->nent++];
|
|
|
|
}
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
static struct kvm_cpuid_entry2 *do_host_cpuid(struct kvm_cpuid_array *array,
|
2020-03-02 15:56:16 -08:00
|
|
|
u32 function, u32 index)
|
2011-11-23 16:30:32 +02:00
|
|
|
{
|
2022-10-22 04:17:53 -04:00
|
|
|
struct kvm_cpuid_entry2 *entry = get_next_cpuid(array);
|
2020-03-02 15:56:19 -08:00
|
|
|
|
2022-10-22 04:17:53 -04:00
|
|
|
if (!entry)
|
2020-03-02 15:56:16 -08:00
|
|
|
return NULL;
|
2020-03-02 15:56:19 -08:00
|
|
|
|
2021-10-28 13:15:55 -04:00
|
|
|
memset(entry, 0, sizeof(*entry));
|
2011-11-23 16:30:32 +02:00
|
|
|
entry->function = function;
|
|
|
|
entry->index = index;
|
2021-10-28 13:15:55 -04:00
|
|
|
switch (function & 0xC0000000) {
|
|
|
|
case 0x40000000:
|
|
|
|
/* Hypervisor leaves are always synthesized by __do_cpuid_func. */
|
|
|
|
return entry;
|
|
|
|
|
2021-10-21 17:19:27 -04: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 08:29:06 -07:00
|
|
|
break;
|
2021-10-21 17:19:27 -04:00
|
|
|
|
2021-10-28 13:15:55 -04:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2019-06-24 10:23:33 +02:00
|
|
|
|
2011-11-23 16:30:32 +02:00
|
|
|
cpuid_count(entry->function, entry->index,
|
|
|
|
&entry->eax, &entry->ebx, &entry->ecx, &entry->edx);
|
2019-07-04 12:20:48 +02:00
|
|
|
|
2022-02-24 10:56:10 -06:00
|
|
|
if (cpuid_function_is_indexed(function))
|
2019-07-04 12:20:48 +02:00
|
|
|
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
|
2020-03-02 15:56:16 -08:00
|
|
|
|
|
|
|
return entry;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
KVM: x86: Treat MONTIOR/MWAIT as a "partially emulated" feature
Enumerate MWAIT in cpuid_func_emulated(), but only if the caller wants to
include "partially emulated" features, i.e. features that KVM kinda sorta
emulates, but with major caveats. This will allow initializing the guest
cpu_caps based on the set of features that KVM virtualizes and/or emulates,
without needing to handle things like MONITOR/MWAIT as one-off exceptions.
Adding one-off handling for individual features is quite painful,
especially when considering future hardening. It's very doable to verify,
at compile time, that every CPUID-based feature that KVM queries when
emulating guest behavior is actually known to KVM, e.g. to prevent KVM
bugs where KVM emulates some feature but fails to advertise support to
userspace. In other words, any features that are special cased, i.e. not
handled generically in the CPUID framework, would also need to be special
cased for any hardening efforts that build on said framework.
Link: https://lore.kernel.org/r/20241128013424.4096668-44-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:10 -08:00
|
|
|
static int cpuid_func_emulated(struct kvm_cpuid_entry2 *entry, u32 func,
|
|
|
|
bool include_partially_emulated)
|
2013-09-22 16:44:50 +02:00
|
|
|
{
|
2024-11-27 17:34:09 -08:00
|
|
|
memset(entry, 0, sizeof(*entry));
|
2020-03-02 15:56:19 -08:00
|
|
|
|
2019-06-24 10:23:33 +02:00
|
|
|
entry->function = func;
|
|
|
|
entry->index = 0;
|
|
|
|
entry->flags = 0;
|
|
|
|
|
2013-10-29 12:54:56 +01:00
|
|
|
switch (func) {
|
|
|
|
case 0:
|
2016-07-12 11:04:26 +02:00
|
|
|
entry->eax = 7;
|
2024-11-27 17:34:09 -08:00
|
|
|
return 1;
|
2013-10-29 12:54:56 +01:00
|
|
|
case 1:
|
2024-11-27 17:33:29 -08:00
|
|
|
entry->ecx = feature_bit(MOVBE);
|
KVM: x86: Treat MONTIOR/MWAIT as a "partially emulated" feature
Enumerate MWAIT in cpuid_func_emulated(), but only if the caller wants to
include "partially emulated" features, i.e. features that KVM kinda sorta
emulates, but with major caveats. This will allow initializing the guest
cpu_caps based on the set of features that KVM virtualizes and/or emulates,
without needing to handle things like MONITOR/MWAIT as one-off exceptions.
Adding one-off handling for individual features is quite painful,
especially when considering future hardening. It's very doable to verify,
at compile time, that every CPUID-based feature that KVM queries when
emulating guest behavior is actually known to KVM, e.g. to prevent KVM
bugs where KVM emulates some feature but fails to advertise support to
userspace. In other words, any features that are special cased, i.e. not
handled generically in the CPUID framework, would also need to be special
cased for any hardening efforts that build on said framework.
Link: https://lore.kernel.org/r/20241128013424.4096668-44-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:10 -08:00
|
|
|
/*
|
|
|
|
* KVM allows userspace to enumerate MONITOR+MWAIT support to
|
|
|
|
* the guest, but the MWAIT feature flag is never advertised
|
|
|
|
* to userspace because MONITOR+MWAIT aren't virtualized by
|
|
|
|
* hardware, can't be faithfully emulated in software (KVM
|
|
|
|
* emulates them as NOPs), and allowing the guest to execute
|
|
|
|
* them natively requires enabling a per-VM capability.
|
|
|
|
*/
|
|
|
|
if (include_partially_emulated)
|
|
|
|
entry->ecx |= feature_bit(MWAIT);
|
2024-11-27 17:34:09 -08:00
|
|
|
return 1;
|
2016-07-12 11:04:26 +02:00
|
|
|
case 7:
|
|
|
|
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
|
2019-06-24 10:23:33 +02:00
|
|
|
entry->eax = 0;
|
2021-05-04 10:17:21 -07:00
|
|
|
if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP))
|
2024-11-27 17:33:29 -08:00
|
|
|
entry->ecx = feature_bit(RDPID);
|
2024-11-27 17:34:09 -08:00
|
|
|
return 1;
|
2013-10-29 12:54:56 +01:00
|
|
|
default:
|
2024-11-27 17:34:09 -08:00
|
|
|
return 0;
|
2013-10-29 12:54:56 +01:00
|
|
|
}
|
2024-11-27 17:34:09 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __do_cpuid_func_emulated(struct kvm_cpuid_array *array, u32 func)
|
|
|
|
{
|
|
|
|
if (array->nent >= array->maxnent)
|
|
|
|
return -E2BIG;
|
2013-10-29 12:54:56 +01:00
|
|
|
|
KVM: x86: Treat MONTIOR/MWAIT as a "partially emulated" feature
Enumerate MWAIT in cpuid_func_emulated(), but only if the caller wants to
include "partially emulated" features, i.e. features that KVM kinda sorta
emulates, but with major caveats. This will allow initializing the guest
cpu_caps based on the set of features that KVM virtualizes and/or emulates,
without needing to handle things like MONITOR/MWAIT as one-off exceptions.
Adding one-off handling for individual features is quite painful,
especially when considering future hardening. It's very doable to verify,
at compile time, that every CPUID-based feature that KVM queries when
emulating guest behavior is actually known to KVM, e.g. to prevent KVM
bugs where KVM emulates some feature but fails to advertise support to
userspace. In other words, any features that are special cased, i.e. not
handled generically in the CPUID framework, would also need to be special
cased for any hardening efforts that build on said framework.
Link: https://lore.kernel.org/r/20241128013424.4096668-44-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-11-27 17:34:10 -08:00
|
|
|
array->nent += cpuid_func_emulated(&array->entries[array->nent], func, false);
|
2013-09-22 16:44:50 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
|
2011-11-23 16:30:32 +02:00
|
|
|
{
|
2020-03-02 15:56:19 -08:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2020-03-02 15:56:17 -08:00
|
|
|
int r, i, max_idx;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
/* all calls to cpuid_count() should be made on the same cpu */
|
|
|
|
get_cpu();
|
2011-11-28 11:20:29 +02:00
|
|
|
|
|
|
|
r = -E2BIG;
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
entry = do_host_cpuid(array, function, 0);
|
2020-03-02 15:56:56 -08:00
|
|
|
if (!entry)
|
2011-11-28 11:20:29 +02:00
|
|
|
goto out;
|
|
|
|
|
2011-11-23 16:30:32 +02:00
|
|
|
switch (function) {
|
|
|
|
case 0:
|
2019-06-06 09:18:45 +08:00
|
|
|
/* Limited to the highest leaf implemented in KVM. */
|
KVM: x86: Advertise AVX10.1 CPUID to userspace
Advertise AVX10.1 related CPUIDs, i.e. report AVX10 support bit via
CPUID.(EAX=07H, ECX=01H):EDX[bit 19] and new CPUID leaf 0x24H so that
guest OS and applications can query the AVX10.1 CPUIDs directly. Intel
AVX10 represents the first major new vector ISA since the introduction of
Intel AVX512, which will establish a common, converged vector instruction
set across all Intel architectures[1].
AVX10.1 is an early version of AVX10, that enumerates the Intel AVX512
instruction set at 128, 256, and 512 bits which is enabled on
Granite Rapids. I.e., AVX10.1 is only a new CPUID enumeration with no
new functionality. New features, e.g. Embedded Rounding and Suppress
All Exceptions (SAE) will be introduced in AVX10.2.
Advertising AVX10.1 is safe because there is nothing to enable for AVX10.1,
i.e. it's purely a new way to enumerate support, thus there will never be
anything for the kernel to enable. Note just the CPUID checking is changed
when using AVX512 related instructions, e.g. if using one AVX512
instruction needs to check (AVX512 AND AVX512DQ), it can check
((AVX512 AND AVX512DQ) OR AVX10.1) after checking XCR0[7:5].
The versions of AVX10 are expected to be inclusive, e.g. version N+1 is
a superset of version N. Per the spec, the version can never be 0, just
advertise AVX10.1 if it's supported in hardware. Moreover, advertising
AVX10_{128,256,512} needs to land in the same commit as advertising basic
AVX10.1 support, otherwise KVM would advertise an impossible CPU model.
E.g. a CPU with AVX512 but not AVX10.1/512 is impossible per the SDM.
As more and more AVX related CPUIDs are added (it would have resulted in
around 40-50 CPUID flags when developing AVX10), the versioning approach
is introduced. But incrementing version numbers are bad for virtualization.
E.g. if AVX10.2 has a feature that shouldn't be enumerated to guests for
whatever reason, then KVM can't enumerate any "later" features either,
because the only way to hide the problematic AVX10.2 feature is to set the
version to AVX10.1 or lower[2]. But most AVX features are just passed
through and don't have virtualization controls, so AVX10 should not be
problematic in practice, so long as Intel honors their promise that future
versions will be supersets of past versions.
[1] https://cdrdv2.intel.com/v1/dl/getContent/784267
[2] https://lore.kernel.org/all/Zkz5Ak0PQlAN8DxK@google.com/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tao Su <tao1.su@linux.intel.com>
Link: https://lore.kernel.org/r/20240819062327.3269720-1-tao1.su@linux.intel.com
[sean: minor changelog tweaks]
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-19 14:23:27 +08:00
|
|
|
entry->eax = min(entry->eax, 0x24U);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
|
|
|
case 1:
|
2020-03-02 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_1_EDX);
|
|
|
|
cpuid_entry_override(entry, CPUID_1_ECX);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2020-03-02 15:56:17 -08: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 15:56:50 -08: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 15:56:51 -08: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 15:56:50 -08:00
|
|
|
* interpret it as an informational descriptor", while AMD's
|
|
|
|
* APM states that CPUID(2) is reserved.
|
2020-03-02 15:56:51 -08: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 15:56:50 -08:00
|
|
|
*/
|
2020-03-02 15:56:51 -08:00
|
|
|
WARN_ON_ONCE((entry->eax & 0xff) > 1);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2019-03-27 13:15:36 -07:00
|
|
|
/* functions 4 and 0x8000001d have additional index. */
|
|
|
|
case 4:
|
2020-03-02 15:56:18 -08:00
|
|
|
case 0x8000001d:
|
|
|
|
/*
|
|
|
|
* Read entries until the cache type in the previous entry is
|
|
|
|
* zero, i.e. indicates an invalid entry.
|
|
|
|
*/
|
2020-03-02 15:56:19 -08:00
|
|
|
for (i = 1; entry->eax & 0x1f; ++i) {
|
|
|
|
entry = do_host_cpuid(array, function, i);
|
|
|
|
if (!entry)
|
2020-03-02 15:56:08 -08:00
|
|
|
goto out;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
break;
|
2015-05-24 17:22:38 +02:00
|
|
|
case 6: /* Thermal management */
|
|
|
|
entry->eax = 0x4; /* allow ARAT */
|
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = 0;
|
|
|
|
break;
|
2019-07-04 12:18:13 +02:00
|
|
|
/* function 7 has additional index. */
|
2020-03-02 15:56:17 -08:00
|
|
|
case 7:
|
2023-10-23 17:16:35 -07:00
|
|
|
max_idx = entry->eax = min(entry->eax, 2u);
|
2020-03-02 15:56:53 -08: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 15:56:48 -08:00
|
|
|
|
2023-10-23 17:16:35 -07:00
|
|
|
/* KVM only supports up to 0x7.2, capped above via min(). */
|
|
|
|
if (max_idx >= 1) {
|
2020-03-02 15:56:49 -08:00
|
|
|
entry = do_host_cpuid(array, function, 1);
|
2020-03-02 15:56:19 -08:00
|
|
|
if (!entry)
|
2019-07-04 12:18:13 +02:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_7_1_EAX);
|
2022-11-25 20:58:43 +08:00
|
|
|
cpuid_entry_override(entry, CPUID_7_1_EDX);
|
2020-03-02 15:56:48 -08:00
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
2019-07-04 12:18:13 +02:00
|
|
|
}
|
2023-10-23 17:16:35 -07:00
|
|
|
if (max_idx >= 2) {
|
|
|
|
entry = do_host_cpuid(array, function, 2);
|
|
|
|
if (!entry)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
cpuid_entry_override(entry, CPUID_7_2_EDX);
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->ebx = 0;
|
|
|
|
entry->eax = 0;
|
|
|
|
}
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2011-11-10 14:57:28 +02:00
|
|
|
case 0xa: { /* Architectural Performance Monitoring */
|
2025-03-14 19:41:02 -07:00
|
|
|
union cpuid10_eax eax = { };
|
|
|
|
union cpuid10_edx edx = { };
|
2011-11-10 14:57:28 +02:00
|
|
|
|
2023-06-02 18:10:52 -07:00
|
|
|
if (!enable_pmu || !static_cpu_has(X86_FEATURE_ARCH_PERFMON)) {
|
2022-04-27 17:01:49 +05:30
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2022-04-11 18:19:44 +08: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 14:57:28 +02:00
|
|
|
|
2022-04-11 18:19:44 +08:00
|
|
|
if (kvm_pmu_cap.version)
|
2021-06-28 15:43:54 +08:00
|
|
|
edx.split.anythread_deprecated = 1;
|
2011-11-10 14:57:28 +02:00
|
|
|
|
|
|
|
entry->eax = eax.full;
|
2022-04-11 18:19:44 +08:00
|
|
|
entry->ebx = kvm_pmu_cap.events_mask;
|
2011-11-10 14:57:28 +02:00
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = edx.full;
|
|
|
|
break;
|
|
|
|
}
|
2019-06-06 09:18:45 +08:00
|
|
|
case 0x1f:
|
2020-03-02 15:56:17 -08:00
|
|
|
case 0xb:
|
2019-09-25 11:17:14 -07:00
|
|
|
/*
|
2022-10-22 04:17:53 -04:00
|
|
|
* No topology; a valid topology is indicated by the presence
|
|
|
|
* of subleaf 1.
|
2019-09-25 11:17:14 -07:00
|
|
|
*/
|
2022-10-22 04:17:53 -04:00
|
|
|
entry->eax = entry->ebx = entry->ecx = 0;
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2022-01-05 04:35:15 -08:00
|
|
|
case 0xd: {
|
2023-04-04 17:45:15 -07:00
|
|
|
u64 permitted_xcr0 = kvm_get_filtered_xcr0();
|
2022-05-24 21:56:23 +08:00
|
|
|
u64 permitted_xss = kvm_caps.supported_xss;
|
2022-01-05 04:35:15 -08:00
|
|
|
|
2022-01-25 19:52:23 +08:00
|
|
|
entry->eax &= permitted_xcr0;
|
|
|
|
entry->ebx = xstate_required_size(permitted_xcr0, false);
|
2014-12-04 18:30:41 +01:00
|
|
|
entry->ecx = entry->ebx;
|
2022-01-25 19:52:23 +08:00
|
|
|
entry->edx &= permitted_xcr0 >> 32;
|
|
|
|
if (!permitted_xcr0)
|
2014-11-21 18:13:26 +01:00
|
|
|
break;
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
entry = do_host_cpuid(array, function, 1);
|
|
|
|
if (!entry)
|
2020-03-02 15:56:09 -08:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_D_1_EAX);
|
2024-11-27 17:33:29 -08:00
|
|
|
if (entry->eax & (feature_bit(XSAVES) | feature_bit(XSAVEC)))
|
2022-01-25 19:52:23 +08:00
|
|
|
entry->ebx = xstate_required_size(permitted_xcr0 | permitted_xss,
|
2020-03-05 16:11:56 +01:00
|
|
|
true);
|
|
|
|
else {
|
2022-01-25 19:52:23 +08:00
|
|
|
WARN_ON_ONCE(permitted_xss != 0);
|
2020-03-02 15:56:19 -08:00
|
|
|
entry->ebx = 0;
|
2020-03-05 16:11:56 +01:00
|
|
|
}
|
2022-01-25 19:52:23 +08:00
|
|
|
entry->ecx &= permitted_xss;
|
|
|
|
entry->edx &= permitted_xss >> 32;
|
2020-03-02 15:56:09 -08:00
|
|
|
|
2020-03-02 15:56:21 -08:00
|
|
|
for (i = 2; i < 64; ++i) {
|
2020-03-05 16:11:56 +01:00
|
|
|
bool s_state;
|
2022-01-25 19:52:23 +08:00
|
|
|
if (permitted_xcr0 & BIT_ULL(i))
|
2020-03-05 16:11:56 +01:00
|
|
|
s_state = false;
|
2022-01-25 19:52:23 +08:00
|
|
|
else if (permitted_xss & BIT_ULL(i))
|
2020-03-05 16:11:56 +01:00
|
|
|
s_state = true;
|
|
|
|
else
|
2020-03-02 15:56:10 -08:00
|
|
|
continue;
|
2020-03-02 15:56:09 -08:00
|
|
|
|
2020-03-02 15:56:21 -08:00
|
|
|
entry = do_host_cpuid(array, function, i);
|
2020-03-02 15:56:19 -08:00
|
|
|
if (!entry)
|
2011-11-28 11:20:29 +02:00
|
|
|
goto out;
|
|
|
|
|
2020-03-02 15:56:11 -08:00
|
|
|
/*
|
2020-03-02 15:56:23 -08:00
|
|
|
* The supported check above should have filtered out
|
2020-03-05 16:11:56 +01:00
|
|
|
* invalid sub-leafs. Only valid sub-leafs should
|
2020-03-02 15:56:11 -08:00
|
|
|
* reach this point, and they should have a non-zero
|
2020-03-05 16:11:56 +01:00
|
|
|
* save state size. Furthermore, check whether the
|
2022-01-25 19:52:23 +08:00
|
|
|
* processor agrees with permitted_xcr0/permitted_xss
|
2020-03-05 16:11:56 +01:00
|
|
|
* on whether this is an XCR0- or IA32_XSS-managed area.
|
2020-03-02 15:56:11 -08:00
|
|
|
*/
|
2020-03-05 16:11:56 +01:00
|
|
|
if (WARN_ON_ONCE(!entry->eax || (entry->ecx & 0x1) != s_state)) {
|
2020-03-02 15:56:19 -08:00
|
|
|
--array->nent;
|
2020-03-02 15:56:09 -08:00
|
|
|
continue;
|
2020-03-02 15:56:12 -08:00
|
|
|
}
|
2022-01-17 15:45:31 +08:00
|
|
|
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_XFD))
|
|
|
|
entry->ecx &= ~BIT_ULL(2);
|
2020-03-02 15:56:19 -08:00
|
|
|
entry->edx = 0;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
break;
|
2022-01-05 04:35:15 -08: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 16:21:42 +12: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 12:13:47 -07: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 16:21:42 +12:00
|
|
|
entry->ebx &= 0;
|
|
|
|
break;
|
2018-10-24 16:05:11 +08:00
|
|
|
/* Intel PT */
|
2020-03-02 15:56:17 -08:00
|
|
|
case 0x14:
|
2020-03-02 15:56:55 -08:00
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT)) {
|
2020-03-02 15:56:26 -08:00
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
2018-10-24 16:05:11 +08:00
|
|
|
break;
|
2020-03-02 15:56:26 -08:00
|
|
|
}
|
2018-10-24 16:05:11 +08:00
|
|
|
|
2020-03-02 15:56:17 -08:00
|
|
|
for (i = 1, max_idx = entry->eax; i <= max_idx; ++i) {
|
2020-03-02 15:56:19 -08:00
|
|
|
if (!do_host_cpuid(array, function, i))
|
2018-10-24 16:05:11 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
break;
|
2022-01-05 04:35:27 -08: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;
|
KVM: x86: Advertise AVX10.1 CPUID to userspace
Advertise AVX10.1 related CPUIDs, i.e. report AVX10 support bit via
CPUID.(EAX=07H, ECX=01H):EDX[bit 19] and new CPUID leaf 0x24H so that
guest OS and applications can query the AVX10.1 CPUIDs directly. Intel
AVX10 represents the first major new vector ISA since the introduction of
Intel AVX512, which will establish a common, converged vector instruction
set across all Intel architectures[1].
AVX10.1 is an early version of AVX10, that enumerates the Intel AVX512
instruction set at 128, 256, and 512 bits which is enabled on
Granite Rapids. I.e., AVX10.1 is only a new CPUID enumeration with no
new functionality. New features, e.g. Embedded Rounding and Suppress
All Exceptions (SAE) will be introduced in AVX10.2.
Advertising AVX10.1 is safe because there is nothing to enable for AVX10.1,
i.e. it's purely a new way to enumerate support, thus there will never be
anything for the kernel to enable. Note just the CPUID checking is changed
when using AVX512 related instructions, e.g. if using one AVX512
instruction needs to check (AVX512 AND AVX512DQ), it can check
((AVX512 AND AVX512DQ) OR AVX10.1) after checking XCR0[7:5].
The versions of AVX10 are expected to be inclusive, e.g. version N+1 is
a superset of version N. Per the spec, the version can never be 0, just
advertise AVX10.1 if it's supported in hardware. Moreover, advertising
AVX10_{128,256,512} needs to land in the same commit as advertising basic
AVX10.1 support, otherwise KVM would advertise an impossible CPU model.
E.g. a CPU with AVX512 but not AVX10.1/512 is impossible per the SDM.
As more and more AVX related CPUIDs are added (it would have resulted in
around 40-50 CPUID flags when developing AVX10), the versioning approach
is introduced. But incrementing version numbers are bad for virtualization.
E.g. if AVX10.2 has a feature that shouldn't be enumerated to guests for
whatever reason, then KVM can't enumerate any "later" features either,
because the only way to hide the problematic AVX10.2 feature is to set the
version to AVX10.1 or lower[2]. But most AVX features are just passed
through and don't have virtualization controls, so AVX10 should not be
problematic in practice, so long as Intel honors their promise that future
versions will be supersets of past versions.
[1] https://cdrdv2.intel.com/v1/dl/getContent/784267
[2] https://lore.kernel.org/all/Zkz5Ak0PQlAN8DxK@google.com/
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Tao Su <tao1.su@linux.intel.com>
Link: https://lore.kernel.org/r/20240819062327.3269720-1-tao1.su@linux.intel.com
[sean: minor changelog tweaks]
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-19 14:23:27 +08:00
|
|
|
case 0x24: {
|
|
|
|
u8 avx10_version;
|
|
|
|
|
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_AVX10)) {
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The AVX10 version is encoded in EBX[7:0]. Note, the version
|
|
|
|
* is guaranteed to be >=1 if AVX10 is supported. Note #2, the
|
|
|
|
* version needs to be captured before overriding EBX features!
|
|
|
|
*/
|
|
|
|
avx10_version = min_t(u8, entry->ebx & 0xff, 1);
|
|
|
|
cpuid_entry_override(entry, CPUID_24_0_EBX);
|
|
|
|
entry->ebx |= avx10_version;
|
|
|
|
|
|
|
|
entry->eax = 0;
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = 0;
|
|
|
|
break;
|
|
|
|
}
|
2011-11-23 16:30:32 +02:00
|
|
|
case KVM_CPUID_SIGNATURE: {
|
2021-11-05 09:51:01 +00:00
|
|
|
const u32 *sigptr = (const u32 *)KVM_SIGNATURE;
|
2012-05-02 17:55:56 +03:00
|
|
|
entry->eax = KVM_CPUID_FEATURES;
|
2011-11-23 16:30:32 +02: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 19:25:07 +03:00
|
|
|
(1 << KVM_FEATURE_PV_EOI) |
|
2013-08-26 14:18:34 +05:30
|
|
|
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
|
2017-12-12 17:33:04 -08:00
|
|
|
(1 << KVM_FEATURE_PV_UNHALT) |
|
2018-02-01 22:16:21 +01: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 14:39:54 +08:00
|
|
|
(1 << KVM_FEATURE_ASYNC_PF_VMEXIT) |
|
2019-06-03 19:52:44 -03:00
|
|
|
(1 << KVM_FEATURE_PV_SEND_IPI) |
|
2019-06-11 20:23:50 +08:00
|
|
|
(1 << KVM_FEATURE_POLL_CONTROL) |
|
2020-05-25 16:41:22 +02:00
|
|
|
(1 << KVM_FEATURE_PV_SCHED_YIELD) |
|
|
|
|
(1 << KVM_FEATURE_ASYNC_PF_INT);
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
if (sched_info_on())
|
|
|
|
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
|
|
|
|
|
|
|
|
entry->ebx = 0;
|
|
|
|
entry->ecx = 0;
|
|
|
|
entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x80000000:
|
2023-06-02 18:10:58 -07:00
|
|
|
entry->eax = min(entry->eax, 0x80000022);
|
2021-10-21 17:19:27 -04:00
|
|
|
/*
|
2022-04-29 14:43:04 -04: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 17:19:27 -04:00
|
|
|
*/
|
2022-04-29 14:43:04 -04:00
|
|
|
if (entry->eax >= 0x8000001d &&
|
|
|
|
(static_cpu_has(X86_FEATURE_LFENCE_RDTSC)
|
|
|
|
|| !static_cpu_has_bug(X86_BUG_NULL_SEG)))
|
2021-10-21 17:19:27 -04:00
|
|
|
entry->eax = max(entry->eax, 0x80000021);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
|
|
|
case 0x80000001:
|
2022-09-30 00:51:58 +02:00
|
|
|
entry->ebx &= ~GENMASK(27, 16);
|
2020-03-02 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0001_EDX);
|
|
|
|
cpuid_entry_override(entry, CPUID_8000_0001_ECX);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2023-07-12 19:31:36 +01:00
|
|
|
case 0x80000005:
|
|
|
|
/* Pass host L1 cache and TLB info. */
|
|
|
|
break;
|
2020-04-14 18:23:20 -07:00
|
|
|
case 0x80000006:
|
2022-09-29 15:51:59 -07:00
|
|
|
/* Drop reserved bits, pass host L2 cache and TLB info. */
|
|
|
|
entry->edx &= ~GENMASK(17, 16);
|
2020-04-14 18:23:20 -07:00
|
|
|
break;
|
2014-04-26 22:30:23 -03:00
|
|
|
case 0x80000007: /* Advanced power management */
|
2022-10-13 11:58:44 +02:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0007_EDX);
|
|
|
|
|
2014-04-26 22:30:23 -03:00
|
|
|
/* mask against host */
|
|
|
|
entry->edx &= boot_cpu_data.x86_power;
|
|
|
|
entry->eax = entry->ebx = entry->ecx = 0;
|
|
|
|
break;
|
2011-11-23 16:30:32 +02:00
|
|
|
case 0x80000008: {
|
2024-03-13 13:58:43 +01:00
|
|
|
/*
|
|
|
|
* GuestPhysAddrSize (EAX[23:16]) is intended for software
|
|
|
|
* use.
|
|
|
|
*
|
|
|
|
* KVM's ABI is to report the effective MAXPHYADDR for the
|
|
|
|
* guest in PhysAddrSize (phys_as), and the maximum
|
|
|
|
* *addressable* GPA in GuestPhysAddrSize (g_phys_as).
|
|
|
|
*
|
|
|
|
* GuestPhysAddrSize is valid if and only if TDP is enabled,
|
|
|
|
* in which case the max GPA that can be addressed by KVM may
|
|
|
|
* be less than the max GPA that can be legally generated by
|
|
|
|
* the guest, e.g. if MAXPHYADDR>48 but the CPU doesn't
|
|
|
|
* support 5-level TDP.
|
|
|
|
*/
|
2024-03-13 13:58:42 +01:00
|
|
|
unsigned int virt_as = max((entry->eax >> 8) & 0xff, 48U);
|
2024-03-13 13:58:43 +01:00
|
|
|
unsigned int phys_as, g_phys_as;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2021-06-23 16:05:46 -07:00
|
|
|
/*
|
2021-06-23 16:05:47 -07: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.
|
|
|
|
*
|
2024-03-13 13:58:42 +01:00
|
|
|
* If TDP is enabled, use the raw bare metal MAXPHYADDR as
|
2024-03-13 13:58:43 +01:00
|
|
|
* reductions to the HPAs do not affect GPAs. The max
|
|
|
|
* addressable GPA is the same as the max effective GPA, except
|
|
|
|
* that it's capped at 48 bits if 5-level TDP isn't supported
|
|
|
|
* (hardware processes bits 51:48 only when walking the fifth
|
|
|
|
* level page table).
|
2021-06-23 16:05:46 -07:00
|
|
|
*/
|
2024-03-13 13:58:42 +01:00
|
|
|
if (!tdp_enabled) {
|
|
|
|
phys_as = boot_cpu_data.x86_phys_bits;
|
2024-03-13 13:58:43 +01:00
|
|
|
g_phys_as = 0;
|
2024-03-13 13:58:42 +01:00
|
|
|
} else {
|
|
|
|
phys_as = entry->eax & 0xff;
|
2011-11-23 16:30:32 +02:00
|
|
|
g_phys_as = phys_as;
|
2024-03-13 13:58:43 +01:00
|
|
|
if (kvm_mmu_get_max_tdp_level() < 5)
|
2025-01-27 09:38:37 +08:00
|
|
|
g_phys_as = min(g_phys_as, 48U);
|
2024-03-13 13:58:42 +01:00
|
|
|
}
|
2021-06-23 16:05:46 -07:00
|
|
|
|
2024-03-13 13:58:43 +01:00
|
|
|
entry->eax = phys_as | (virt_as << 8) | (g_phys_as << 16);
|
2022-09-29 15:52:00 -07:00
|
|
|
entry->ecx &= ~(GENMASK(31, 16) | GENMASK(11, 8));
|
2018-02-01 22:59:43 +01:00
|
|
|
entry->edx = 0;
|
2020-03-02 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0008_EBX);
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
|
|
|
}
|
2020-03-02 15:57:09 -08: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 16:30:32 +02:00
|
|
|
case 0x80000019:
|
|
|
|
entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x8000001a:
|
2022-09-29 15:52:01 -07:00
|
|
|
entry->eax &= GENMASK(2, 0);
|
|
|
|
entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
2019-03-27 13:15:37 -07:00
|
|
|
case 0x8000001e:
|
2022-10-22 04:17:53 -04:00
|
|
|
/* Do not return host topology information. */
|
|
|
|
entry->eax = entry->ebx = entry->ecx = 0;
|
|
|
|
entry->edx = 0; /* reserved */
|
2011-11-23 16:30:32 +02:00
|
|
|
break;
|
2019-11-21 12:33:43 -08:00
|
|
|
case 0x8000001F:
|
2021-06-23 16:05:47 -07:00
|
|
|
if (!kvm_cpu_cap_has(X86_FEATURE_SEV)) {
|
2019-11-21 12:33:43 -08:00
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
2021-06-23 16:05:47 -07:00
|
|
|
} else {
|
2021-04-21 19:11:15 -07:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_001F_EAX);
|
2022-09-29 15:52:03 -07:00
|
|
|
/* Clear NumVMPL since KVM does not support VMPL. */
|
|
|
|
entry->ebx &= ~GENMASK(31, 12);
|
2021-06-23 16:05:47 -07:00
|
|
|
/*
|
|
|
|
* Enumerate '0' for "PA bits reduction", the adjusted
|
|
|
|
* MAXPHYADDR is enumerated directly (see 0x80000008).
|
|
|
|
*/
|
|
|
|
entry->ebx &= ~GENMASK(11, 6);
|
|
|
|
}
|
2019-11-21 12:33:43 -08:00
|
|
|
break;
|
2021-10-28 13:26:38 -04:00
|
|
|
case 0x80000020:
|
|
|
|
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
|
|
|
|
break;
|
|
|
|
case 0x80000021:
|
2024-09-11 11:00:50 +02:00
|
|
|
entry->ebx = entry->edx = 0;
|
2023-01-24 10:33:13 -06:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0021_EAX);
|
2024-09-11 11:00:50 +02:00
|
|
|
cpuid_entry_override(entry, CPUID_8000_0021_ECX);
|
2021-10-28 13:26:38 -04:00
|
|
|
break;
|
2023-06-02 18:10:58 -07:00
|
|
|
/* AMD Extended Performance Monitoring and Debug */
|
|
|
|
case 0x80000022: {
|
2025-03-14 19:41:02 -07:00
|
|
|
union cpuid_0x80000022_ebx ebx = { };
|
2023-06-02 18:10:58 -07:00
|
|
|
|
|
|
|
entry->ecx = entry->edx = 0;
|
|
|
|
if (!enable_pmu || !kvm_cpu_cap_has(X86_FEATURE_PERFMON_V2)) {
|
2025-03-04 03:23:14 -05:00
|
|
|
entry->eax = entry->ebx = 0;
|
2023-06-02 18:10:58 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpuid_entry_override(entry, CPUID_8000_0022_EAX);
|
|
|
|
|
2025-03-04 03:23:13 -05:00
|
|
|
ebx.split.num_core_pmc = kvm_pmu_cap.num_counters_gp;
|
2023-06-02 18:10:58 -07:00
|
|
|
entry->ebx = ebx.full;
|
|
|
|
break;
|
|
|
|
}
|
2011-11-23 16:30:32 +02: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 15:56:53 -08:00
|
|
|
cpuid_entry_override(entry, CPUID_C000_0001_EDX);
|
2011-11-23 16:30:32 +02: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 11:20:29 +02:00
|
|
|
r = 0;
|
|
|
|
|
|
|
|
out:
|
2011-11-23 16:30:32 +02:00
|
|
|
put_cpu();
|
2011-11-28 11:20:29 +02:00
|
|
|
|
|
|
|
return r;
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
static int do_cpuid_func(struct kvm_cpuid_array *array, u32 func,
|
|
|
|
unsigned int type)
|
2013-09-22 16:44:50 +02:00
|
|
|
{
|
|
|
|
if (type == KVM_GET_EMULATED_CPUID)
|
2020-03-02 15:56:19 -08:00
|
|
|
return __do_cpuid_func_emulated(array, func);
|
2013-09-22 16:44:50 +02:00
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
return __do_cpuid_func(array, func);
|
2013-09-22 16:44:50 +02:00
|
|
|
}
|
|
|
|
|
2020-03-02 15:56:06 -08:00
|
|
|
#define CENTAUR_CPUID_SIGNATURE 0xC0000000
|
2011-11-28 11:20:29 +02:00
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
static int get_cpuid_func(struct kvm_cpuid_array *array, u32 func,
|
|
|
|
unsigned int type)
|
2020-03-02 15:56:05 -08:00
|
|
|
{
|
|
|
|
u32 limit;
|
|
|
|
int r;
|
|
|
|
|
2020-03-02 15:56:06 -08:00
|
|
|
if (func == CENTAUR_CPUID_SIGNATURE &&
|
|
|
|
boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR)
|
|
|
|
return 0;
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
r = do_cpuid_func(array, func, type);
|
2020-03-02 15:56:05 -08:00
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
limit = array->entries[array->nent - 1].eax;
|
2020-03-02 15:56:05 -08:00
|
|
|
for (func = func + 1; func <= limit; ++func) {
|
2020-03-02 15:56:19 -08:00
|
|
|
r = do_cpuid_func(array, func, type);
|
2020-03-02 15:56:05 -08:00
|
|
|
if (r)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2013-09-22 16:44:50 +02:00
|
|
|
static bool sanity_check_entries(struct kvm_cpuid_entry2 __user *entries,
|
|
|
|
__u32 num_entries, unsigned int ioctl_type)
|
|
|
|
{
|
|
|
|
int i;
|
2013-11-06 15:46:02 +01:00
|
|
|
__u32 pad[3];
|
2013-09-22 16:44:50 +02: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 15:46:02 +01:00
|
|
|
if (copy_from_user(pad, entries[i].padding, sizeof(pad)))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (pad[0] || pad[1] || pad[2])
|
2013-09-22 16:44:50 +02: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 16:30:32 +02:00
|
|
|
{
|
2020-03-02 15:56:06 -08:00
|
|
|
static const u32 funcs[] = {
|
|
|
|
0, 0x80000000, CENTAUR_CPUID_SIGNATURE, KVM_CPUID_SIGNATURE,
|
2011-11-28 11:20:29 +02:00
|
|
|
};
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
struct kvm_cpuid_array array = {
|
|
|
|
.nent = 0,
|
|
|
|
};
|
|
|
|
int r, i;
|
2020-03-02 15:56:07 -08:00
|
|
|
|
2011-11-23 16:30:32 +02:00
|
|
|
if (cpuid->nent < 1)
|
2020-03-02 15:56:07 -08:00
|
|
|
return -E2BIG;
|
2011-11-23 16:30:32 +02:00
|
|
|
if (cpuid->nent > KVM_MAX_CPUID_ENTRIES)
|
|
|
|
cpuid->nent = KVM_MAX_CPUID_ENTRIES;
|
2013-09-22 16:44:50 +02:00
|
|
|
|
|
|
|
if (sanity_check_entries(entries, cpuid->nent, type))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2022-11-03 09:17:49 +08:00
|
|
|
array.entries = kvcalloc(cpuid->nent, sizeof(struct kvm_cpuid_entry2), GFP_KERNEL);
|
2020-03-02 15:56:19 -08:00
|
|
|
if (!array.entries)
|
2020-03-02 15:56:07 -08:00
|
|
|
return -ENOMEM;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2020-06-04 12:16:36 +08:00
|
|
|
array.maxnent = cpuid->nent;
|
|
|
|
|
2020-03-02 15:56:06 -08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(funcs); i++) {
|
2020-03-02 15:56:19 -08:00
|
|
|
r = get_cpuid_func(&array, funcs[i], type);
|
2011-11-28 11:20:29 +02:00
|
|
|
if (r)
|
2011-11-23 16:30:32 +02:00
|
|
|
goto out_free;
|
|
|
|
}
|
2020-03-02 15:56:19 -08:00
|
|
|
cpuid->nent = array.nent;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
2020-03-02 15:56:19 -08:00
|
|
|
if (copy_to_user(entries, array.entries,
|
|
|
|
array.nent * sizeof(struct kvm_cpuid_entry2)))
|
2020-03-02 15:56:07 -08:00
|
|
|
r = -EFAULT;
|
2011-11-23 16:30:32 +02:00
|
|
|
|
|
|
|
out_free:
|
2022-03-08 04:57:39 -05:00
|
|
|
kvfree(array.entries);
|
2011-11-23 16:30:32 +02:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
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-04 17:34:34 -08: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 15:28:01 +01: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-04 17:34:34 -08: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 16:30:32 +02:00
|
|
|
*/
|
2020-03-04 17:34:36 -08:00
|
|
|
static struct kvm_cpuid_entry2 *
|
|
|
|
get_out_of_range_cpuid_entry(struct kvm_vcpu *vcpu, u32 *fn_ptr, u32 index)
|
2011-11-23 16:30:32 +02: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-04 17:34:34 -08:00
|
|
|
struct kvm_cpuid_entry2 *basic, *class;
|
2020-03-04 17:34:36 -08: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-04 17:34:34 -08:00
|
|
|
|
2022-07-12 02:06:45 +02: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-04 17:34:34 -08:00
|
|
|
if (!basic)
|
2020-03-04 17:34:36 -08: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-04 17:34:34 -08:00
|
|
|
|
|
|
|
if (function >= 0x40000000 && function <= 0x4fffffff)
|
2022-07-12 02:06:45 +02: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-04 17:34:34 -08:00
|
|
|
else if (function >= 0xc0000000)
|
2022-07-12 02:06:45 +02: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-04 17:34:34 -08:00
|
|
|
else
|
2022-07-12 02:06:45 +02:00
|
|
|
class = kvm_find_cpuid_entry(vcpu, function & 0x80000000);
|
2019-09-25 17:04:17 -07:00
|
|
|
|
2020-03-04 17:34:36 -08: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 02:06:45 +02:00
|
|
|
return kvm_find_cpuid_entry_index(vcpu, basic->eax, index);
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
|
2017-08-24 20:27:52 +08:00
|
|
|
bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
|
2020-03-04 17:34:37 -08:00
|
|
|
u32 *ecx, u32 *edx, bool exact_only)
|
2011-11-23 16:30:32 +02:00
|
|
|
{
|
2020-03-04 17:34:31 -08:00
|
|
|
u32 orig_function = *eax, function = *eax, index = *ecx;
|
2019-09-25 17:04:17 -07:00
|
|
|
struct kvm_cpuid_entry2 *entry;
|
2020-03-17 12:53:54 -07:00
|
|
|
bool exact, used_max_basic = false;
|
2017-08-24 20:27:52 +08:00
|
|
|
|
KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation
Defer runtime CPUID updates until the next non-faulting CPUID emulation
or KVM_GET_CPUID2, which are the only paths in KVM that consume the
dynamic entries. Deferring the updates is especially beneficial to
nested VM-Enter/VM-Exit, as KVM will almost always detect multiple state
changes, not to mention the updates don't need to be realized while L2 is
active if CPUID is being intercepted by L1 (CPUID is a mandatory intercept
on Intel, but not AMD).
Deferring CPUID updates shaves several hundred cycles from nested VMX
roundtrips, as measured from L2 executing CPUID in a tight loop:
SKX 6850 => 6450
ICX 9000 => 8800
EMR 7900 => 7700
Alternatively, KVM could update only the CPUID leaves that are affected
by the state change, e.g. update XSAVE info only if XCR0 or XSS changes,
but that adds non-trivial complexity and doesn't solve the underlying
problem of nested transitions potentially changing both XCR0 and XSS, on
both nested VM-Enter and VM-Exit.
Skipping updates entirely if L2 is active and CPUID is being intercepted
by L1 could work for the common case. However, simply skipping updates if
L2 is active is *very* subtly dangerous and complex. Most KVM updates are
triggered by changes to the current vCPU state, which may be L2 state,
whereas performing updates only for L1 would requiring detecting changes
to L1 state. KVM would need to either track relevant L1 state, or defer
runtime CPUID updates until the next nested VM-Exit. The former is ugly
and complex, while the latter comes with similar dangers to deferring all
CPUID updates, and would only address the nested VM-Enter path.
To guard against using stale data, disallow querying dynamic CPUID feature
bits, i.e. features that KVM updates at runtime, via a compile-time
assertion in guest_cpu_cap_has(). Exempt MWAIT from the rule, as the
MISC_ENABLE_NO_MWAIT means that MWAIT is _conditionally_ a dynamic CPUID
feature.
Note, the rule could be enforced for MWAIT as well, e.g. by querying guest
CPUID in kvm_emulate_monitor_mwait, but there's no obvious advtantage to
doing so, and allowing MWAIT for guest_cpuid_has() opens up a different can
of worms. MONITOR/MWAIT can't be virtualized (for a reasonable definition),
and the nature of the MWAIT_NEVER_UD_FAULTS and MISC_ENABLE_NO_MWAIT quirks
means checking X86_FEATURE_MWAIT outside of kvm_emulate_monitor_mwait() is
wrong for other reasons.
Beyond the aforementioned feature bits, the only other dynamic CPUID
(sub)leaves are the XSAVE sizes, and similar to MWAIT, consuming those
CPUID entries in KVM is all but guaranteed to be a bug. The layout for an
actual XSAVE buffer depends on the format (compacted or not) and
potentially the features that are actually enabled. E.g. see the logic in
fpstate_clear_xstate_component() needed to poke into the guest's effective
XSAVE state to clear MPX state on INIT. KVM does consume
CPUID.0xD.0.{EAX,EDX} in kvm_check_cpuid() and cpuid_get_supported_xcr0(),
but not EBX, which is the only dynamic output register in the leaf.
Link: https://lore.kernel.org/r/20241211013302.1347853-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-12-10 17:33:02 -08:00
|
|
|
if (vcpu->arch.cpuid_dynamic_bits_dirty)
|
|
|
|
kvm_update_cpuid_runtime(vcpu);
|
|
|
|
|
2022-07-12 02:06:45 +02:00
|
|
|
entry = kvm_find_cpuid_entry_index(vcpu, function, index);
|
2020-03-04 17:34:37 -08:00
|
|
|
exact = !!entry;
|
2020-03-04 17:34:36 -08:00
|
|
|
|
2020-03-17 12:53:54 -07:00
|
|
|
if (!entry && !exact_only) {
|
2020-03-04 17:34:36 -08:00
|
|
|
entry = get_out_of_range_cpuid_entry(vcpu, &function, index);
|
2020-03-17 12:53:54 -07:00
|
|
|
used_max_basic = !!entry;
|
|
|
|
}
|
2020-03-04 17:34:36 -08:00
|
|
|
|
2019-09-25 17:04:17 -07:00
|
|
|
if (entry) {
|
|
|
|
*eax = entry->eax;
|
|
|
|
*ebx = entry->ebx;
|
|
|
|
*ecx = entry->ecx;
|
|
|
|
*edx = entry->edx;
|
2019-11-18 12:23:00 -05:00
|
|
|
if (function == 7 && index == 0) {
|
|
|
|
u64 data;
|
2024-12-10 17:33:00 -08:00
|
|
|
if ((*ebx & (feature_bit(RTM) | feature_bit(HLE))) &&
|
|
|
|
!__kvm_get_msr(vcpu, MSR_IA32_TSX_CTRL, &data, true) &&
|
2019-11-18 12:23:00 -05:00
|
|
|
(data & TSX_CTRL_CPUID_CLEAR))
|
2024-11-27 17:33:29 -08:00
|
|
|
*ebx &= ~(feature_bit(RTM) | feature_bit(HLE));
|
2022-10-13 11:58:45 +02:00
|
|
|
} else if (function == 0x80000007) {
|
|
|
|
if (kvm_hv_invtsc_suppressed(vcpu))
|
2024-11-27 17:33:28 -08:00
|
|
|
*edx &= ~feature_bit(CONSTANT_TSC);
|
2025-01-24 15:05:39 +00:00
|
|
|
} else if (IS_ENABLED(CONFIG_KVM_XEN) &&
|
|
|
|
kvm_xen_is_tsc_leaf(vcpu, function)) {
|
|
|
|
/*
|
|
|
|
* Update guest TSC frequency information if necessary.
|
|
|
|
* Ignore failures, there is no sane value that can be
|
|
|
|
* provided if KVM can't get the TSC frequency.
|
|
|
|
*/
|
|
|
|
if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, vcpu))
|
|
|
|
kvm_guest_time_update(vcpu);
|
|
|
|
|
|
|
|
if (index == 1) {
|
KVM Xen changes for 6.15
- Don't write to the Xen hypercall page on MSR writes that are initiated by
the host (userspace or KVM) to fix a class of bugs where KVM can write to
guest memory at unexpected times, e.g. during vCPU creation if userspace has
set the Xen hypercall MSR index to collide with an MSR that KVM emulates.
- Restrict the Xen hypercall MSR indx to the unofficial synthetic range to
reduce the set of possible collisions with MSRs that are emulated by KVM
(collisions can still happen as KVM emulates Hyper-V MSRs, which also reside
in the synthetic range).
- Clean up and optimize KVM's handling of Xen MSR writes and xen_hvm_config.
- Update Xen TSC leaves during CPUID emulation instead of modifying the CPUID
entries when updating PV clocks, as there is no guarantee PV clocks will be
updated between TSC frequency changes and CPUID emulation, and guest reads
of Xen TSC should be rare, i.e. are not a hot path.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmfZpO4ACgkQOlYIJqCj
N/3AMQ/+J4+yOslekq4DHYhZaTvJFf0MqhPgTuf2s6I5p449JWn9rebqK2w0M9Xj
fJy7/rboQA4QflBuhTiWcC3Dl1lYtxUqqtcCH9608eqKhbeay87OfV0/vgMwWBRs
FhcOcp1587esJj5gz5M5R9i3S5Yq7Q4fp1+DmS23X41Zz5nTb2q80MY5UklMgI9I
Ydaw1liB8rRHWbdt9yM4UsI8k4fMuj0PE8pEapoTSfsZm8J4cG9qHKrvuWjuFSCF
l18Hyl11nWq8eZ5Vg2E2UIz0EgtWIHKu1/fi4av20/JTuA8Mon15WC5q4BBmDDdD
keR9OJLYclVBh8KweiJSTUE6PcD9A8pWmoWyp6aGRiyyUVhbwysYTzT7uytwQz6w
RH/vVHe0o/m19SnD9rqsRVObc7dOGorFXScMcf4Qxoq9yQm2p0lJDvq6c9uECLMV
RIfZrXe9HS67RB9INybS+1fVlLcd0bLgGfG7q9lWLEABD45HpM5daQ4Mlf8+MIE0
V7egx9t69/WALbJka8pWNISeFRKkB1LRjite+XXasqJ0iFeneM8UKFVB4OMtXL9g
M0m8ovvySySMkoCq3yMlKxXh4rJ1/D556/bAaJBukMPWFWX9FQaP33U3FuzId7jH
ztZVugViQMNiIbQVgUSAcgpuJvgpttAciACODlaw2u2Bk1Txmn0=
=c3Wt
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-xen-6.15' of https://github.com/kvm-x86/linux into HEAD
KVM Xen changes for 6.15
- Don't write to the Xen hypercall page on MSR writes that are initiated by
the host (userspace or KVM) to fix a class of bugs where KVM can write to
guest memory at unexpected times, e.g. during vCPU creation if userspace has
set the Xen hypercall MSR index to collide with an MSR that KVM emulates.
- Restrict the Xen hypercall MSR indx to the unofficial synthetic range to
reduce the set of possible collisions with MSRs that are emulated by KVM
(collisions can still happen as KVM emulates Hyper-V MSRs, which also reside
in the synthetic range).
- Clean up and optimize KVM's handling of Xen MSR writes and xen_hvm_config.
- Update Xen TSC leaves during CPUID emulation instead of modifying the CPUID
entries when updating PV clocks, as there is no guarantee PV clocks will be
updated between TSC frequency changes and CPUID emulation, and guest reads
of Xen TSC should be rare, i.e. are not a hot path.
2025-03-19 09:14:59 -04:00
|
|
|
*ecx = vcpu->arch.pvclock_tsc_mul;
|
|
|
|
*edx = vcpu->arch.pvclock_tsc_shift;
|
2025-01-24 15:05:39 +00:00
|
|
|
} else if (index == 2) {
|
|
|
|
*eax = vcpu->arch.hw_tsc_khz;
|
|
|
|
}
|
2019-11-18 12:23:00 -05:00
|
|
|
}
|
2019-09-25 17:04:17 -07:00
|
|
|
} else {
|
2012-06-07 14:07:48 +03:00
|
|
|
*eax = *ebx = *ecx = *edx = 0;
|
2019-09-25 17:04:17 -07: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 02:06:45 +02:00
|
|
|
entry = kvm_find_cpuid_entry_index(vcpu, function, 1);
|
2019-09-25 17:04:17 -07:00
|
|
|
if (entry) {
|
|
|
|
*ecx = index & 0xff;
|
|
|
|
*edx = entry->edx;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-03-17 12:53:54 -07:00
|
|
|
trace_kvm_cpuid(orig_function, index, *eax, *ebx, *ecx, *edx, exact,
|
|
|
|
used_max_basic);
|
2020-03-04 17:34:37 -08:00
|
|
|
return exact;
|
2012-06-07 14:07:48 +03:00
|
|
|
}
|
2012-12-05 15:26:19 +01:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_cpuid);
|
2012-06-07 14:07:48 +03:00
|
|
|
|
2016-11-29 12:40:37 -08:00
|
|
|
int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
|
2012-06-07 14:07:48 +03:00
|
|
|
{
|
2016-11-07 08:55:49 +08:00
|
|
|
u32 eax, ebx, ecx, edx;
|
2012-06-07 14:07:48 +03:00
|
|
|
|
2017-03-20 01:16:28 -07:00
|
|
|
if (cpuid_fault_enabled(vcpu) && !kvm_require_cpl(vcpu, 0))
|
|
|
|
return 1;
|
|
|
|
|
2019-04-30 10:36:17 -07:00
|
|
|
eax = kvm_rax_read(vcpu);
|
|
|
|
ecx = kvm_rcx_read(vcpu);
|
2020-03-04 17:34:37 -08:00
|
|
|
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx, false);
|
2019-04-30 10:36:17 -07: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 12:40:40 -08:00
|
|
|
return kvm_skip_emulated_instruction(vcpu);
|
2011-11-23 16:30:32 +02:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
|