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

[Jeff Law <law@redhat.com>]

On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:

>
> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV guest
> still crashes on that machine) - which means that in multi-lib the bit_YMM_Usable
> is _not_ set. But then looking at the sources I see:
What's even more amusing?  Just after installing the incorrect feature 
check and introducing bit_YMM_Usable, Uli reverted all the tests which 
had been checking for usable YMM regs and made them check AVX again.

  one.
>
> Perhaps this is needed:
>
> --- glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c.orig	2012-05-09 13:32:10.832000122 -0400
> +++ glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c	2012-05-09 13:33:31.043000138 -0400
> @@ -154,6 +154,8 @@ __init_cpu_features (void)
>   		     : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0));
>   		(xcrlow&  6) == 6; }))
>   	__cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable;
> +	else
> +	__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx&= ~bit_AVX;
>       }
>
>     __cpu_features.family = family;
I certainly agree.  The big problem here is testing...  I still can't 
test it :(  Against my better judgment I may have to throw a glibc with 
that change over the wall and hope.  There's been far too much of that 
already.

jeff