From: Maxim Levitsky <mlevitsk@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>,
Jiri Olsa <jolsa@kernel.org>,
linux-perf-users@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
Borislav Petkov <bp@alien8.de>, Kees Cook <keescook@chromium.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)),
Jane Malalane <jane.malalane@citrix.com>,
Tony Luck <tony.luck@intel.com>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-crypto@vger.kernel.org (open list:CRYPTO API),
Paolo Bonzini <pbonzini@redhat.com>
Subject: [PATCH 4/4] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them
Date: Wed, 22 Jun 2022 17:48:20 +0300 [thread overview]
Message-ID: <20220622144820.751402-5-mlevitsk@redhat.com> (raw)
In-Reply-To: <20220622144820.751402-1-mlevitsk@redhat.com>
Due to configuration bugs, sometimes a CPU feature is disabled in CPUID,
but not features that depend on it.
While the above is not supported, the kernel should try to not crash,
and clearing the dependent cpu caps is the best way to do it.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
arch/x86/kernel/cpu/common.c | 4 ++--
arch/x86/kernel/cpu/cpuid-deps.c | 27 +++++++++++++++++++++++++--
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4cc79971d2d847..c83a8f447d6aed 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1469,7 +1469,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
this_cpu->c_early_init(c);
c->cpu_index = 0;
- filter_cpuid_features(c, false);
+ filter_cpuid_features(c, true);
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
@@ -1757,7 +1757,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
*/
/* Filter out anything that depends on CPUID levels we don't have */
- filter_cpuid_features(c, true);
+ filter_cpuid_features(c, false);
/* If the model name is still unset, do table lookup. */
if (!c->x86_model_id[0]) {
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index bcb091d02a754b..6d9c0e39851805 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -94,6 +94,11 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature)
set_bit(feature, (unsigned long *)cpu_caps_cleared);
}
+static inline bool test_feature(struct cpuinfo_x86 *c, unsigned int feature)
+{
+ return test_bit(feature, (unsigned long *)c->x86_capability);
+}
+
/* Take the capabilities and the BUG bits into account */
#define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8)
@@ -127,6 +132,7 @@ void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
} while (changed);
}
+
void setup_clear_cpu_cap(unsigned int feature)
{
clear_cpu_cap(&boot_cpu_data, feature);
@@ -137,6 +143,10 @@ void setup_clear_cpu_cap(unsigned int feature)
* Some CPU features depend on higher CPUID levels, which may not always
* be available due to CPUID level capping or broken virtualization
* software. Add those features to this table to auto-disable them.
+ *
+ * Also due to configuration bugs, some CPUID features might be present
+ * while CPUID features that they depend on are not present,
+ * e.g a AVX2 present but AVX is not present.
*/
struct cpuid_dependent_feature {
u32 feature;
@@ -151,9 +161,10 @@ cpuid_dependent_features[] = {
{ 0, 0 }
};
-void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
+void filter_cpuid_features(struct cpuinfo_x86 *c, bool early)
{
const struct cpuid_dependent_feature *df;
+ const struct cpuid_dep *d;
for (df = cpuid_dependent_features; df->feature; df++) {
@@ -172,10 +183,22 @@ void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
continue;
clear_cpu_cap(c, df->feature);
- if (!warn)
+ if (early)
continue;
pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n",
x86_cap_flag(df->feature), df->level);
}
+
+ for (d = cpuid_deps; d->feature; d++) {
+
+ if (!test_feature(c, d->feature) || test_feature(c, d->depends))
+ continue;
+
+ clear_feature(c, d->feature);
+
+ pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, because it depends on "
+ X86_CAP_FMT " which is not supported in CPUID\n",
+ x86_cap_flag(d->feature), x86_cap_flag(d->depends));
+ }
}
--
2.26.3
next prev parent reply other threads:[~2022-06-22 14:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 14:48 [PATCH 0/4] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-06-22 14:48 ` [PATCH 1/4] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
2022-06-22 14:58 ` Dave Hansen
2022-06-22 18:57 ` Liang, Kan
2022-06-22 19:32 ` Liang, Kan
2022-06-22 14:48 ` [PATCH 2/4] x86/cpuid: refactor setup_clear_cpu_cap/clear_feature Maxim Levitsky
2022-06-22 15:07 ` Dave Hansen
2022-06-22 15:59 ` Maxim Levitsky
2022-06-22 14:48 ` [PATCH 3/4] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
2022-06-22 15:07 ` Dave Hansen
2022-06-22 16:01 ` Maxim Levitsky
2022-06-22 14:48 ` Maxim Levitsky [this message]
2022-06-22 15:32 ` [PATCH 4/4] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Dave Hansen
2022-06-22 17:09 ` Maxim Levitsky
2022-06-22 17:18 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220622144820.751402-5-mlevitsk@redhat.com \
--to=mlevitsk@redhat.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jane.malalane@citrix.com \
--cc=jolsa@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).