[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <49BA3A84.76E4.0078.0@novell.com>
Date: Fri, 13 Mar 2009 09:50:44 +0000
From: "Jan Beulich" <jbeulich@...ell.com>
To: "Jeremy Fitzhardinge" <jeremy@...p.org>,
"H. Peter Anvin" <hpa@...or.com>
Cc: "Jeremy Fitzhardinge" <jeremy.fitzhardinge@...rix.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
"Xen-devel" <xen-devel@...ts.xensource.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/24] xen: mask XSAVE from cpuid
>>> Jeremy Fitzhardinge <jeremy@...p.org> 13.03.09 09:11 >>>
>From: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
>
>Xen leaves XSAVE set in cpuid, but doesn't allow cr4.OSXSAVE
>to be set. This confuses the kernel and it ends up crashing on
>an xsetbv instruction.
>
>At boot time, try to set cr4.OSXSAVE, and mask XSAVE out of
>cpuid it we can't. This will produce a spurious error from Xen,
>but allows us to support XSAVE if/when Xen does.
As pointed out on an earlier thread, it seems inappropriate to do probing
like this when there is a cpuid feature flag (osxsave) that can be used to
determine whether XSAVE can be used. And even without that flag,
simply reading CR4 and checking whether osxsave is set there would
suffice. This is under the assumption that Xen's to-be-done implementation
of XSAVE support would match that of FXSAVE (Xen turns its support on
unconditionally and for all [pv] guests).
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists