All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>,
	"David S. Miller" <davem@davemloft.net>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Jane Malalane <jane.malalane@citrix.com>,
	Kees Cook <keescook@chromium.org>,
	Kan Liang <kan.liang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Maxim Levitsky <mlevitsk@redhat.com>,
	x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)),
	Herbert Xu <herbert@gondor.apana.org.au>,
	Jiri Olsa <jolsa@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
	linux-perf-users@vger.kernel.org,
	linux-crypto@vger.kernel.org (open list:CRYPTO API)
Subject: [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them
Date: Mon, 18 Jul 2022 17:11:23 +0300	[thread overview]
Message-ID: <20220718141123.136106-6-mlevitsk@redhat.com> (raw)
In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com>

Due to configuration bugs, sometimes a CPU feature is disabled in CPUID,
but not features that depend on it.

For example, when one attempts to disable AVX2 but not AVX in the
guest's CPUID, the guest kernel crashes in aes-ni driver, when it
is used.

While the aes-ni driver can also be fixed to be more eager to detect this kind
of situation, it is simpler to fix this in a generic way since the kernel
has all the required info in the form of a dependency table.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/kernel/cpu/cpuid-deps.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index e1b5f5c02c0106..376296c1f55ab2 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)
 
@@ -136,6 +141,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;
@@ -153,6 +162,7 @@ cpuid_dependent_features[] = {
 void filter_cpuid_features(struct cpuinfo_x86 *c)
 {
 	const struct cpuid_dependent_feature *df;
+	const struct cpuid_dep *d;
 
 	for (df = cpuid_dependent_features; df->feature; df++) {
 
@@ -175,4 +185,16 @@ void filter_cpuid_features(struct cpuinfo_x86 *c)
 		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_cpu_cap(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.34.3


  parent reply	other threads:[~2022-07-18 14:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
2022-09-19 14:31   ` Borislav Petkov
2022-09-20  8:20     ` Maxim Levitsky
2022-09-26 13:12       ` Borislav Petkov
2022-09-28 10:49         ` Maxim Levitsky
2022-10-20  8:59           ` Borislav Petkov
2022-10-20  9:05             ` Herbert Xu
2022-10-20 10:21               ` Maxim Levitsky
2022-10-20 11:13                 ` Borislav Petkov
2022-10-22 21:08             ` H. Peter Anvin
2022-11-02 13:40             ` Paolo Bonzini
2022-11-02 14:27               ` Elliott, Robert (Servers)
2022-11-02 16:23                 ` H. Peter Anvin
2022-11-02 18:19                   ` H. Peter Anvin
2022-11-02 19:14                     ` Elliott, Robert (Servers)
2022-11-03 13:26                   ` Paolo Bonzini
2022-11-03 13:30                 ` Paolo Bonzini
2022-10-20 15:17   ` [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap() tip-bot2 for Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
2022-10-21 16:19   ` Borislav Petkov
2022-11-07 19:10     ` Borislav Petkov
2022-11-07 21:57       ` Borislav Petkov
2022-07-18 14:11 ` [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Maxim Levitsky
2022-07-18 14:11 ` Maxim Levitsky [this message]
2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-08-01 16:05   ` Maxim Levitsky
2022-08-01 16:31     ` Dave Hansen
2022-08-01 16:41       ` Maxim Levitsky
2022-09-19 13:43     ` Maxim Levitsky

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=20220718141123.136106-6-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=jpoimboe@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.