2010-07-19 18:32:04 -07:00
|
|
|
/*
|
2013-10-12 01:29:46 +02:00
|
|
|
* Routines to identify additional cpu features that are scattered in
|
2010-07-19 18:32:04 -07:00
|
|
|
* cpuid space.
|
|
|
|
*/
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
|
2019-11-20 15:33:57 +01:00
|
|
|
#include <asm/memtype.h>
|
2018-12-05 00:34:56 +01:00
|
|
|
#include <asm/apic.h>
|
2010-07-19 18:32:04 -07:00
|
|
|
#include <asm/processor.h>
|
|
|
|
|
2018-12-05 00:34:56 +01:00
|
|
|
#include "cpu.h"
|
2010-07-19 18:32:04 -07:00
|
|
|
|
|
|
|
struct cpuid_bit {
|
|
|
|
u16 feature;
|
|
|
|
u8 reg;
|
|
|
|
u8 bit;
|
|
|
|
u32 level;
|
|
|
|
u32 sub_leaf;
|
|
|
|
};
|
|
|
|
|
2018-11-21 20:28:41 +00:00
|
|
|
/*
|
|
|
|
* Please keep the leaf sorted by cpuid_bit.level for faster search.
|
|
|
|
* X86_FEATURE_MBA is supported by both Intel and AMD. But the CPUID
|
|
|
|
* levels are different and there is a separate entry for each.
|
|
|
|
*/
|
2016-11-11 17:25:35 +08:00
|
|
|
static const struct cpuid_bit cpuid_bits[] = {
|
|
|
|
{ X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 },
|
2016-11-16 14:19:34 +01:00
|
|
|
{ X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 },
|
2022-01-31 15:01:08 -08:00
|
|
|
{ X86_FEATURE_INTEL_PPIN, CPUID_EBX, 0, 0x00000007, 1 },
|
2022-07-08 13:36:09 -07:00
|
|
|
{ X86_FEATURE_RRSBA_CTRL, CPUID_EDX, 2, 0x00000007, 2 },
|
2019-06-19 18:51:09 +02:00
|
|
|
{ X86_FEATURE_CQM_LLC, CPUID_EDX, 1, 0x0000000f, 0 },
|
|
|
|
{ X86_FEATURE_CQM_OCCUP_LLC, CPUID_EDX, 0, 0x0000000f, 1 },
|
|
|
|
{ X86_FEATURE_CQM_MBM_TOTAL, CPUID_EDX, 1, 0x0000000f, 1 },
|
|
|
|
{ X86_FEATURE_CQM_MBM_LOCAL, CPUID_EDX, 2, 0x0000000f, 1 },
|
2016-11-16 14:19:34 +01:00
|
|
|
{ X86_FEATURE_CAT_L3, CPUID_EBX, 1, 0x00000010, 0 },
|
|
|
|
{ X86_FEATURE_CAT_L2, CPUID_EBX, 2, 0x00000010, 0 },
|
|
|
|
{ X86_FEATURE_CDP_L3, CPUID_ECX, 2, 0x00000010, 1 },
|
2017-12-20 14:57:21 -08:00
|
|
|
{ X86_FEATURE_CDP_L2, CPUID_ECX, 2, 0x00000010, 2 },
|
2017-04-07 17:33:52 -07:00
|
|
|
{ X86_FEATURE_MBA, CPUID_EBX, 3, 0x00000010, 0 },
|
2020-08-24 12:11:20 -07:00
|
|
|
{ X86_FEATURE_PER_THREAD_MBA, CPUID_ECX, 0, 0x00000010, 3 },
|
2021-03-19 20:22:18 +13:00
|
|
|
{ X86_FEATURE_SGX1, CPUID_EAX, 0, 0x00000012, 0 },
|
|
|
|
{ X86_FEATURE_SGX2, CPUID_EAX, 1, 0x00000012, 0 },
|
KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest
The new Asynchronous Exit (AEX) notification mechanism (AEX-notify)
allows one enclave to receive a notification in the ERESUME after the
enclave exit due to an AEX. EDECCSSA is a new SGX user leaf function
(ENCLU[EDECCSSA]) to facilitate the AEX notification handling. The new
EDECCSSA is enumerated via CPUID(EAX=0x12,ECX=0x0):EAX[11].
Besides Allowing reporting the new AEX-notify attribute to KVM guests,
also allow reporting the new EDECCSSA user leaf function to KVM guests
so the guest can fully utilize the AEX-notify mechanism.
Similar to existing X86_FEATURE_SGX1 and X86_FEATURE_SGX2, introduce a
new scattered X86_FEATURE_SGX_EDECCSSA bit for the new EDECCSSA, and
report it in KVM's supported CPUIDs.
Note, no additional KVM enabling is required to allow the guest to use
EDECCSSA. It's impossible to trap ENCLU (without completely preventing
the guest from using SGX). Advertise EDECCSSA as supported purely so
that userspace doesn't need to special case EDECCSSA, i.e. doesn't need
to manually check host CPUID.
The inability to trap ENCLU also means that KVM can't prevent the guest
from using EDECCSSA, but that virtualization hole is benign as far as
KVM is concerned. EDECCSSA is simply a fancy way to modify internal
enclave state.
More background about how do AEX-notify and EDECCSSA work:
SGX maintains a Current State Save Area Frame (CSSA) for each enclave
thread. When AEX happens, the enclave thread context is saved to the
CSSA and the CSSA is increased by 1. For a normal ERESUME which doesn't
deliver AEX notification, it restores the saved thread context from the
previously saved SSA and decreases the CSSA. If AEX-notify is enabled
for one enclave, the ERESUME acts differently. Instead of restoring the
saved thread context and decreasing the CSSA, it acts like EENTER which
doesn't decrease the CSSA but establishes a clean slate thread context
using the CSSA for the enclave to handle the notification. After some
handling, the enclave must discard the "new-established" SSA and switch
back to the previously saved SSA (upon AEX). Otherwise, the enclave
will run out of SSA space upon further AEXs and eventually fail to run.
To solve this problem, the new EDECCSSA essentially decreases the CSSA.
It can be used by the enclave notification handler to switch back to the
previous saved SSA when needed, i.e. after it handles the notification.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Sean Christopherson <seanjc@google.com>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/all/20221101022422.858944-1-kai.huang%40intel.com
2022-11-01 15:24:22 +13:00
|
|
|
{ X86_FEATURE_SGX_EDECCSSA, CPUID_EAX, 11, 0x00000012, 0 },
|
2016-11-16 14:19:34 +01:00
|
|
|
{ X86_FEATURE_HW_PSTATE, CPUID_EDX, 7, 0x80000007, 0 },
|
|
|
|
{ X86_FEATURE_CPB, CPUID_EDX, 9, 0x80000007, 0 },
|
2016-11-11 17:25:35 +08:00
|
|
|
{ X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 },
|
2018-11-21 20:28:41 +00:00
|
|
|
{ X86_FEATURE_MBA, CPUID_EBX, 6, 0x80000008, 0 },
|
2023-01-13 09:20:28 -06:00
|
|
|
{ X86_FEATURE_SMBA, CPUID_EBX, 2, 0x80000020, 0 },
|
2023-01-13 09:20:30 -06:00
|
|
|
{ X86_FEATURE_BMEC, CPUID_EBX, 3, 0x80000020, 0 },
|
2022-04-21 11:16:53 +05:30
|
|
|
{ X86_FEATURE_PERFMON_V2, CPUID_EAX, 0, 0x80000022, 0 },
|
2022-08-11 17:59:52 +05:30
|
|
|
{ X86_FEATURE_AMD_LBR_V2, CPUID_EAX, 1, 0x80000022, 0 },
|
2016-11-11 17:25:35 +08:00
|
|
|
{ 0, 0, 0, 0, 0 }
|
2010-07-19 18:32:04 -07:00
|
|
|
};
|
|
|
|
|
x86: delete __cpuinit usage from all x86 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings. In any case, they are temporary and harmless.
This removes all the arch/x86 uses of the __cpuinit macros from
all C files. x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-06-18 18:23:59 -04:00
|
|
|
void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
|
2010-07-19 18:32:04 -07:00
|
|
|
{
|
|
|
|
u32 max_level;
|
|
|
|
u32 regs[4];
|
|
|
|
const struct cpuid_bit *cb;
|
|
|
|
|
|
|
|
for (cb = cpuid_bits; cb->feature; cb++) {
|
|
|
|
|
|
|
|
/* Verify that the level is valid */
|
|
|
|
max_level = cpuid_eax(cb->level & 0xffff0000);
|
|
|
|
if (max_level < cb->level ||
|
|
|
|
max_level > (cb->level | 0xffff))
|
|
|
|
continue;
|
|
|
|
|
2016-11-11 17:25:34 +08:00
|
|
|
cpuid_count(cb->level, cb->sub_leaf, ®s[CPUID_EAX],
|
|
|
|
®s[CPUID_EBX], ®s[CPUID_ECX],
|
|
|
|
®s[CPUID_EDX]);
|
2010-07-19 18:32:04 -07:00
|
|
|
|
|
|
|
if (regs[cb->reg] & (1 << cb->bit))
|
|
|
|
set_cpu_cap(c, cb->feature);
|
|
|
|
}
|
|
|
|
}
|