From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Jonathan McDowell <noodles@earth.li>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH v7 2/5] x86/cpuid: Add generic table for cpuid dependencies
Date: Thu, 5 Oct 2017 15:25:52 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1710051508180.2083@nanos> (raw)
In-Reply-To: <20171004234930.5685-3-andi@firstfloor.org>
On Wed, 4 Oct 2017, Andi Kleen wrote:
Cc: +Borislav
> v2: Add EXPORT_SYMBOL for clear_cpu_id for lguest
clear_cpu_id? You probably mean clear_cpu_cap, but that's moot now that
lguest is gone......
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
...
> #define set_cpu_cap(c, bit) set_bit(bit, (unsigned long *)((c)->x86_capability))
> -#define clear_cpu_cap(c, bit) clear_bit(bit, (unsigned long *)((c)->x86_capability))
> -#define setup_clear_cpu_cap(bit) do { \
> +#define __clear_cpu_cap(c, bit) clear_bit(bit, (unsigned long *)((c)->x86_capability))
>
> +
> +extern void setup_clear_cpu_cap(int bit);
> +extern void clear_cpu_cap(struct cpuinfo_x86 *cpu, int bit);
> +
> +#define __setup_clear_cpu_cap(bit) do { \
> clear_cpu_cap(&boot_cpu_data, bit); \
> set_bit(bit, (unsigned long *)cpu_caps_cleared); \
> } while (0)
__clear_cpu_cap() and __setup_clear_cpu_cap() should not be in the header
file. They should be in the new cpuid-deps file so they are not
exposed. While at it please implement them as inlines. There is no reason
for having them as macros.
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -0,0 +1,94 @@
> +/* Declare dependencies between CPUIDs */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <asm/cpufeature.h>
> +
> +struct cpuid_dep {
> + int feature;
> + int disable;
> +};
> +
> +/*
> + * Table of CPUID features that depend on others.
> + *
> + * This only includes dependencies that can be usefully disabled, not
> + * features part of the base set (like FPU).
> + */
> +const static struct cpuid_dep cpuid_deps[] = {
> + { X86_FEATURE_XSAVE, X86_FEATURE_XSAVEOPT },
> + { X86_FEATURE_XSAVE, X86_FEATURE_XSAVEC },
> + { X86_FEATURE_XSAVE, X86_FEATURE_XSAVES },
> + { X86_FEATURE_XSAVE, X86_FEATURE_AVX },
> + { X86_FEATURE_XSAVE, X86_FEATURE_AVX512F },
> + { X86_FEATURE_XSAVE, X86_FEATURE_PKU },
> + { X86_FEATURE_XSAVE, X86_FEATURE_MPX },
> + { X86_FEATURE_XSAVE, X86_FEATURE_XGETBV1 },
> + { X86_FEATURE_XMM, X86_FEATURE_XMM2 },
> + { X86_FEATURE_XMM2, X86_FEATURE_XMM3 },
> + { X86_FEATURE_XMM2, X86_FEATURE_XMM4_1 },
> + { X86_FEATURE_XMM2, X86_FEATURE_XMM4_2 },
> + { X86_FEATURE_XMM2, X86_FEATURE_XMM3 },
> + { X86_FEATURE_XMM2, X86_FEATURE_PCLMULQDQ },
> + { X86_FEATURE_XMM2, X86_FEATURE_SSSE3 },
> + { X86_FEATURE_XMM2, X86_FEATURE_F16C },
> + { X86_FEATURE_XMM2, X86_FEATURE_AES },
> + { X86_FEATURE_FMA, X86_FEATURE_AVX },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512IFMA },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512PF },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512ER },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512CD },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512DQ },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512BW },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512VL },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512VBMI },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_4VNNIW },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_4FMAPS },
> + { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_VPOPCNTDQ },
> + { X86_FEATURE_AVX, X86_FEATURE_AVX2 },
> + {}
> +};
> +
> +static inline void clearfeat(struct cpuinfo_x86 *cpu, int feat)
What's wrong with giving this a readable name like clear_feature()? That
function name is definitely not a feat.
*cpu is the worst argument name you could come up with. I was not paying
attention when skimming the patch and assumed that the 'if (!cpu)' check
tests for cpu == 0, aka boot cpu.
Also the feature argument wants to be unsigned int all over the place.
> +{
> + if (!cpu)
> + __setup_clear_cpu_cap(feat);
> + else
> + __clear_cpu_cap(cpu, feat);
> +}
> +
> +static void do_clear_cpu_cap(struct cpuinfo_x86 *cpu, int feat)
> +{
> + bool changed;
> + __u32 disable[NCAPINTS + NBUGINTS];
> + unsigned long *disable_mask = (unsigned long *)disable;
> + const struct cpuid_dep *d;
> +
> + clearfeat(cpu, feat);
> +
> + /* Collect all features to disable, handling dependencies */
> + memset(disable, 0, sizeof(disable));
> + __set_bit(feat, disable_mask);
> + do {
> + changed = false;
> + for (d = cpuid_deps; d->feature; d++) {
> + if (test_bit(d->feature, disable_mask) &&
> + !__test_and_set_bit(d->disable, disable_mask)) {
The logic of this dependency structure is backwards. As the name says its
supposed to express dependencies. So it should actually do so:
struct cpuid_dep {
unsigned int feature;
unsigned int depends;
};
Then the logic here becomes immediately obvious:
for (d = cpuid_deps; d->feature; d++) {
if (!test_bit(d->depends, disabled_mask))
continue;
if (test_and_set_bit(d->feature, disabled_mask))
continue;
changed = true;
clear_feature(cpuinfo, d->feature);
}
Hmm?
Thanks,
tglx
next prev parent reply other threads:[~2017-10-05 13:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 23:49 Support generic disabling of all XSAVE features Andi Kleen
2017-10-04 23:49 ` [PATCH v7 1/5] x86/xsave: Move xsave initialization to after parsing early parameters Andi Kleen
2017-10-05 13:04 ` Thomas Gleixner
2017-10-04 23:49 ` [PATCH v7 2/5] x86/cpuid: Add generic table for cpuid dependencies Andi Kleen
2017-10-05 13:25 ` Thomas Gleixner [this message]
2017-10-04 23:49 ` [PATCH v7 3/5] x86/cpuid: Make clearcpuid an early param Andi Kleen
2017-10-05 13:26 ` Thomas Gleixner
2017-10-04 23:49 ` [PATCH v7 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling Andi Kleen
2017-10-05 13:31 ` Thomas Gleixner
2017-10-04 23:49 ` [PATCH v7 5/5] x86/xsave: Using generic CPUID clearing when disabling XSAVE Andi Kleen
2017-10-05 13:44 ` Thomas Gleixner
-- strict thread matches above, loose matches on Subject: below --
2017-09-19 22:26 Support generic disabling of all XSAVE features Andi Kleen
2017-09-19 22:26 ` [PATCH v7 2/5] x86/cpuid: Add generic table for cpuid dependencies Andi Kleen
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=alpine.DEB.2.20.1710051508180.2083@nanos \
--to=tglx@linutronix.de \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=noodles@earth.li \
--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
all inboxes | Powered by JetHome®