From: Sean Christopherson <seanjc@google.com>
To: Sohil Mehta <sohil.mehta@intel.com>
Cc: x86@kernel.org, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
Uros Bizjak <ubizjak@gmail.com>,
Sandipan Das <sandipan.das@amd.com>,
Peter Zijlstra <peterz@infradead.org>,
Vegard Nossum <vegard.nossum@oracle.com>,
Tony Luck <tony.luck@intel.com>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
Eric Biggers <ebiggers@google.com>, Xin Li <xin3.li@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] x86/cpufeature: Add feature dependency checks
Date: Thu, 22 Aug 2024 16:27:13 -0700 [thread overview]
Message-ID: <ZsfJUT0AWFhoONWf@google.com> (raw)
In-Reply-To: <20240822202226.862398-1-sohil.mehta@intel.com>
On Thu, Aug 22, 2024, Sohil Mehta wrote:
> Currently, the cpuid-deps[] table is only exercised when a particular
> feature gets explicitly disabled and clear_cpu_cap() is called. However,
> some of these listed dependencies might already be missing during boot.
> Unexpected failures can occur when the kernel tries to use such a
> feature.
>
> Therefore, add boot time checks for missing feature dependencies and
> disable any feature whose dependencies are not met.
>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> Arguably, this situation should only happen on broken hardware and it may not
> make sense to add such a check to the kernel. OTOH, this can be viewed as a
> safety mechanism to make failures more graceful on such configurations in real
> or virtual environments.
And goofy Kconfigs. But yeah, lack of any meaningful fallout is why my version
didn't go anywhere.
https://lore.kernel.org/all/20221203003745.1475584-2-seanjc@google.com
> I feel since we already have the cpuid-deps[] table and the incremental changes
> are small, this patch might be a useful addition.
>
> Also, if this check seems worthwhile, would it be useful to combine and rewrite
> it with filter_cpuid_features() since it tries to do something similar?
> ---
>
> arch/x86/include/asm/cpufeature.h | 1 +
> arch/x86/kernel/cpu/common.c | 4 ++++
> arch/x86/kernel/cpu/cpuid-deps.c | 10 ++++++++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index 0b9611da6c53..347ef04f65ef 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -148,6 +148,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
>
> extern void setup_clear_cpu_cap(unsigned int bit);
> extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
> +extern void filter_feature_dependencies(struct cpuinfo_x86 *c);
>
> #define setup_force_cpu_cap(bit) do { \
> \
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index d4e539d4e158..6b725dbd8db7 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1602,6 +1602,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>
> c->cpu_index = 0;
> filter_cpuid_features(c, false);
> + filter_feature_dependencies(c);
>
> if (this_cpu->c_bsp_init)
> this_cpu->c_bsp_init(c);
> @@ -1854,6 +1855,9 @@ 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 out features that don't have their dependencies met */
> + filter_feature_dependencies(c);
> +
> /* If the model name is still unset, do table lookup. */
> if (!c->x86_model_id[0]) {
> const char *p;
> diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
> index b7d9f530ae16..88b34a97278a 100644
> --- a/arch/x86/kernel/cpu/cpuid-deps.c
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -147,3 +147,13 @@ void setup_clear_cpu_cap(unsigned int feature)
> {
> do_clear_cpu_cap(NULL, feature);
> }
> +
> +void filter_feature_dependencies(struct cpuinfo_x86 *c)
> +{
> + const struct cpuid_dep *d;
> +
> + for (d = cpuid_deps; d->feature; d++) {
> + if (boot_cpu_has(d->feature) && !boot_cpu_has(d->depends))
I don't think checking boot_cpu_has() is correct, it's entirely possible for a CPU
to have divergent features from the boot CPU, e.g. if a feature is dependent on
BIOS enabling (or disabling) and BIOS messed up.
> + do_clear_cpu_cap(c, d->feature);
> + }
> +}
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-08-22 23:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 20:22 [RFC PATCH] x86/cpufeature: Add feature dependency checks Sohil Mehta
2024-08-22 23:27 ` Sean Christopherson [this message]
2024-08-23 19:05 ` Sohil Mehta
2024-08-26 20:05 ` Sean Christopherson
2024-08-26 21:47 ` Sohil Mehta
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=ZsfJUT0AWFhoONWf@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=ubizjak@gmail.com \
--cc=vegard.nossum@oracle.com \
--cc=x86@kernel.org \
--cc=xin3.li@intel.com \
/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.