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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.05.12 at 21:39, Jeff Law <law@xxxxxxxxxx> wrote:
> On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> 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.
>>
>> It has this:
>> 146
>> 147   if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx&  bit_AVX)
>> 148     {
>> 149       /* Reset the AVX bit in case OSXSAVE is disabled.  */
>> 150       if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx&  bit_OSXSAVE) 
> != 0
>> 151&&  ({ unsigned int xcrlow;
>> 152                 unsigned int xcrhigh;
>> 153                 asm ("xgetbv"
>> 154                      : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0));
>> 155                 (xcrlow&  6) == 6; }))
>> 156         __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable;
>> 157     }
>>
>>
>> And when I ran a little silly C program (attached) to probe the CPUID flags, 
> I got:
>>   /root/test-xsave
>> SSE3 CMOV
>> AVX  XSAVE
>> Trying XGETBV
>> Illegal instruction (core dumped)
>>
>> 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:
>>
>> # ifdef USE_AS_STRCASECMP_L
>> 102 ENTRY(__strcasecmp)
>> 103         .type   __strcasecmp, @gnu_indirect_function
>> 104         cmpl    $0, __cpu_features+KIND_OFFSET(%rip)
>> 105         jne     1f
>> 106         call    __init_cpu_features
>> 107 1:
>> 108 #  ifdef HAVE_AVX_SUPPORT
>> 109         leaq    __strcasecmp_avx(%rip), %rax
>> 110         testl   $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip)
>> 111         jnz     2f
>> 112 #  endif
>>
>> which would imply that the AVX bit is sampled here instead of the
>> YMM one.
> [ ... ]
> I think Uli's position is that this code only uses AVX encodings, but 
> not the YMM registers and thus the right check is for AVX.

Which is wrong: (Almost?) all VEX encoded operations act on the full
YMM registers, even if they operate only on 128 bits - the upper 128
bits get zeroed in that case.

Plus all exception type descriptions in the SDM are clearly indicating
that VEX encoded AVX instructions require CR4.OSXSAVE (mirrored
in CPUID.OSXSAVE) to be set along with the corresponding specific
CPUID feature flag(s).

Jan


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