From: Suresh Siddha <suresh.b.siddha@intel.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
Avuton Olrich <avuton@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: Fail to early boot with v2.6.27-rc2 to at least v2.6.29-rc2 due to dc1e35c
Date: Thu, 22 Jan 2009 14:22:50 -0800 [thread overview]
Message-ID: <20090122222250.GI28352@linux-os.sc.intel.com> (raw)
In-Reply-To: <87bpu1dyl6.fsf@basil.nowhere.org>
On Tue, Jan 20, 2009 at 09:20:37PM -0800, Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> >
> > We should, or if this block is reversible, we should probably just
> > undo it (the reason people put this block in places is because of,
> > ahem, inferior operating systems having bugs.)
>
> Even if it's undone it would be still a good idea to make the cpuid
> code bulletproof, just in case someone writes a broken emulator or similar.
Ok. Here is the patch for this aswell. Thanks.
---
From: Suresh Siddha <suresh.b.siddha@intel.com>
Subject: [patch] x86: check for the presence of cpuid xsave leaf
Avuton Olrich reported early boot crashes with v2.6.28 and
bisected it down to dc1e35c6e95e8923cf1d3510438b63c600fee1e2
("x86, xsave: enable xsave/xrstor on cpus with xsave support").
Root cause of this showed that bios has enabled the "Max CPUID Value Limit:"
option which confuses the kernel by showing xsave capability without
the cpuid xsave leaf.
Peter fixed the impact of bios limiting the cpuid limit by checking
for the limit bit set in the MSR_IA32_MISC_ENABLE is set and clearing it.
Andi suggests to make xsave code also bulletproof, just incase if someone
writes a broken simulator.
Check for the presence of CPUID_XSAVE_LEAF before enabling it.
Reported-and-bisected-by: Avuton Olrich <avuton@gmail.com>
Tested-by: Avuton Olrich <avuton@gmail.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
diff --git a/arch/x86/include/asm/xsave.h b/arch/x86/include/asm/xsave.h
index 08e9a1a..96bb62f 100644
--- a/arch/x86/include/asm/xsave.h
+++ b/arch/x86/include/asm/xsave.h
@@ -27,7 +27,7 @@ extern unsigned int xstate_size;
extern u64 pcntxt_mask;
extern struct xsave_struct *init_xstate_buf;
-extern void xsave_cntxt_init(void);
+extern int xsave_cntxt_init(void);
extern void xsave_init(void);
extern int init_fpu(struct task_struct *child);
extern int check_for_xstate(struct i387_fxsave_struct __user *buf,
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index b0f61f0..2e2e8b1 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -65,10 +65,8 @@ void __cpuinit init_thread_xstate(void)
return;
}
- if (cpu_has_xsave) {
- xsave_cntxt_init();
+ if (!xsave_cntxt_init())
return;
- }
if (cpu_has_fxsr)
xstate_size = sizeof(struct i387_fxsave_struct);
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 2b54fe0..5384a3b 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -307,14 +307,25 @@ static void __init setup_xstate_init(void)
init_xstate_buf->i387.mxcsr = MXCSR_DEFAULT;
}
+#define CPUID_XSAVE_LEAF 0xd
+
/*
* Enable and initialize the xsave feature.
*/
-void __ref xsave_cntxt_init(void)
+int __ref xsave_cntxt_init(void)
{
unsigned int eax, ebx, ecx, edx;
- cpuid_count(0xd, 0, &eax, &ebx, &ecx, &edx);
+ if (!cpu_has_xsave)
+ return -1;
+
+ if (boot_cpu_data.cpuid_level < CPUID_XSAVE_LEAF) {
+ printk(KERN_ERR "cpuid xsave leaf 0xd not supported\n");
+ setup_clear_cpu_cap(X86_FEATURE_XSAVE);
+ return -1;
+ }
+
+ cpuid_count(CPUID_XSAVE_LEAF, 0, &eax, &ebx, &ecx, &edx);
pcntxt_mask = eax + ((u64)edx << 32);
if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
@@ -342,4 +353,5 @@ void __ref xsave_cntxt_init(void)
printk(KERN_INFO "xsave/xrstor: enabled xstate_bv 0x%llx, "
"cntxt size 0x%x\n",
pcntxt_mask, xstate_size);
+ return 0;
}
next prev parent reply other threads:[~2009-01-22 22:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-19 14:04 Fail to early boot with v2.6.27-rc2 to at least v2.6.29-rc2 due to dc1e35c Avuton Olrich
2009-01-19 14:28 ` Avuton Olrich
2009-01-19 18:55 ` H. Peter Anvin
2009-01-19 19:31 ` Avuton Olrich
2009-01-19 20:07 ` H. Peter Anvin
2009-01-19 20:11 ` Suresh Siddha
2009-01-19 21:46 ` Avuton Olrich
2009-01-19 21:57 ` Suresh Siddha
2009-01-19 22:07 ` H. Peter Anvin
2009-01-19 22:14 ` Suresh Siddha
2009-01-19 22:24 ` H. Peter Anvin
2009-01-21 5:20 ` Andi Kleen
2009-01-22 22:22 ` Suresh Siddha [this message]
2009-01-22 22:40 ` H. Peter Anvin
2009-01-22 22:56 ` Suresh Siddha
2009-01-20 3:35 ` Valdis.Kletnieks
2009-01-20 6:36 ` H. Peter Anvin
2009-01-22 0:38 ` H. Peter Anvin
2009-01-22 2:26 ` Avuton Olrich
2009-01-22 8:28 ` Ingo Molnar
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=20090122222250.GI28352@linux-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=andi@firstfloor.org \
--cc=avuton@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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