From: "H. Peter Anvin" <hpa@zytor.com>
To: brgerst@gmail.com, luto@kernel.org, bp@alien8.de,
linux-kernel@vger.kernel.org, mingo@kernel.org,
tglx@linutronix.de, linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
Date: Mon, 19 Dec 2016 23:05:07 -0800 [thread overview]
Message-ID: <c4d21625-2513-45ee-a1ea-320bfe30d2d8@zytor.com> (raw)
In-Reply-To: <tip-3df8d9208569ef0b2313e516566222d745f3b94b@git.kernel.org>
On 12/19/16 02:56, tip-bot for Andy Lutomirski wrote:
> Commit-ID: 3df8d9208569ef0b2313e516566222d745f3b94b
> Gitweb: http://git.kernel.org/tip/3df8d9208569ef0b2313e516566222d745f3b94b
> Author: Andy Lutomirski <luto@kernel.org>
> AuthorDate: Thu, 15 Dec 2016 10:14:42 -0800
> Committer: Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Mon, 19 Dec 2016 11:50:24 +0100
>
> x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
>
> A typo (or mis-merge?) resulted in leaf 6 only being probed if
> cpuid_level >= 7.
>
> Fixes: 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature bits to x86_capability")
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> Acked-by: Borislav Petkov <bp@alien8.de>
> Cc: Brian Gerst <brgerst@gmail.com>
> Link: http://lkml.kernel.org/r/6ea30c0e9daec21e488b54761881a6dfcf3e04d0.1481825597.git.luto@kernel.org
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> ---
> arch/x86/kernel/cpu/common.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 1f6b50a..dc1697c 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -667,13 +667,14 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> c->x86_capability[CPUID_1_EDX] = edx;
> }
>
> + /* Thermal and Power Management Leaf: level 0x00000006 (eax) */
> + if (c->cpuid_level >= 0x00000006)
> + c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x00000006);
> +
> /* Additional Intel-defined flags: level 0x00000007 */
> if (c->cpuid_level >= 0x00000007) {
> cpuid_count(0x00000007, 0, &eax, &ebx, &ecx, &edx);
> -
> c->x86_capability[CPUID_7_0_EBX] = ebx;
> -
> - c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x00000006);
> c->x86_capability[CPUID_7_ECX] = ecx;
> }
Perhaps we should have something like:
void cpuid_cond(u32 leaf, u32 subleaf,
u32 *eax, u32 *ebx, u32 *ecx, u32 *edx)
{
const struct cpuinfo_x86 *c = this_cpu_ptr(&cpu_info);
u32 maxleaf;
int cpuid_level = c->cpuid_level;
switch (leaf >> 16) {
case 0x0000:
maxleaf = c->cpuid_level;
break;
case 0x8000:
maxleaf = c->extended_cpuid_level;
break;
case 0x4000 .. 0x40ff:
/* Not ideal, can we do better? */
maxleaf = cpu_has(X86_FEATURE_HYPERVISOR)
? 0x40ffffff : 0;
break;
/* Add Transmeta 0x8086 and VIA/Cyrix 0xc000? */
default:
/* Can we do better? */
if (c->x86_vendor_id) == X86_VENDOR_INTEL)
maxleaf = 0;
else
maxleaf = leaf | 0xffff;
break;
}
if (cpuid_level >= 0 && leaf >= maxleaf) {
cpuid_count(leaf, subleaf, eax, ebx, ecx, edx);
} else {
*eax = *ebx = *ecx = *edx = 0;
}
}
-hpa
P.S. I would love to (a) move the CPUID bits into a structure instead of
passing all those crazy pointers around, and (b) stop passing struct
cpuinfo * around when we only use it for the current processor anyway (a
lot of these functions are in fact completely invalid if we don't); we
could define this_cpu_info as (*this_cpu_ptr(&cpu_info)) -- basically
what I have above -- or directly use percpu functions to access these
variables.
next prev parent reply other threads:[~2016-12-20 7:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 18:14 [PATCH] " Andy Lutomirski
2016-12-15 19:17 ` Borislav Petkov
2016-12-19 10:56 ` [tip:x86/urgent] " tip-bot for Andy Lutomirski
2016-12-20 7:05 ` H. Peter Anvin [this message]
2016-12-20 9:27 ` Thomas Gleixner
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=c4d21625-2513-45ee-a1ea-320bfe30d2d8@zytor.com \
--to=hpa@zytor.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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®