Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.05.12 at 15:11, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote:
>> > After some digging around, it looks like this is an Ubuntu 11.10 only 
> patch:
>> > 
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fb 
> a59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b82416
> 0b
>> 
>> 
>> Ugh. There are looks to be a bug in Fedora as well: 
> https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this.
>> 
> 
> CC-ing Intel. It seems that the userspace programs are crashingon
> Sandybridge machines even if 'xsave=0' is provided on the command line.
> Any advice?

Going through the bug, all I can see are bogus attempts to pass
"xsave=" (with value 0 or 1) to the kernel. That's a hypervisor
option though, and the only kernel option that's relevant here
is "noxsave" afaik.

Further, when the hypervisor has xsave support enabled, there's
(in the pv case) nothing the kernel can do to hide the functionality
from applications, as the hardware's CR4.OSXSAVE will be set, and
hence CPUID.OSXSAVE will be too. So "noxsave" on the kernel
command line when "xsave=1" (or xsave enabled by default as in
4.2) just doesn't make any sense.

And finally one always has to keep in mind that there is this nice
glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE
when trying to determine whether AVX or FMA is available.

Jan

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel