Bug 13753

In the process of backporting.

See bug #14059, you should add the following part from my patch as well (full patch for review at http://sourceware.org/ml/libc-alpha/2012-05/msg00321.html):

2012-05-08  Jim Westfall  <jwestfall@surrealistic.net>

        [BZ #14059]
        * sysdeps/x86_64/multiarch/init-arch.c (__init_cpu_features):
        Disable FMA4 if AVX is disabled.

+  /* FMA4 depends on AVX support.  */
+  if (__cpu_features.cpuid[COMMON_CPUID_INDEX_80000001].ecx & bit_FMA4
+      && (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) == 0)
+    __cpu_features.cpuid[COMMON_CPUID_INDEX_80000001].ecx &= ~bit_FMA4;

I've also got reports that Uli's patch is wrong because it can leave AVX enabled even though OSXSAVE is off. 

My understanding is:

1. OSXSAVE must be enabled
2. AVX must be enabled
3. XGETBV must have XMM & XMM state enabled

Otherwise AVX can not be used.

This (for example) causes Xen to fail miserably.

Jeff,

Do the commits and patch in question in this issue fix AVX usage for you? In other words will we be backporting the right stuff for 2.15.1?

No, the code on the trunk plus the patch in this BZ are not sufficient to fix the problem AFAIK. Unfortunately I don't have the right hardware to do testing, so I'm relying on other folks.

I've got a change which I hope fixes this problem, but I'm going to have to wait for feedback.  Based on my understanding we really need to avoid using any AVX if the OS doesn't support XSAVE, even for things which don't use the YMM regs.

@Jeff: I have access to a Xen system to test these issues, so if you post a link to the patch I can test.

Note that with the two original patches I still get issues in strcasecmp() with illegal instructions with AVX:

#0  0x00007ffff76cd0ff in __strcasecmp_l_avx () from ./lib/libc.so.6

   0x00007ffff76cd0f7 <+23>:	and    $0x3f,%rcx
   0x00007ffff76cd0fb <+27>:	and    $0x3f,%rax
=> 0x00007ffff76cd0ff <+31>:	vmovdqa 0x46979(%rip),%xmm4        # 0x7ffff7713a80
   0x00007ffff76cd107 <+39>:	vmovdqa 0x469a1(%rip),%xmm5        # 0x7ffff7713ab0
   0x00007ffff76cd10f <+47>:	vmovdqa 0x46989(%rip),%xmm6        # 0x7ffff7713aa0

I will test with the additional patches linked in this bug report.


BTW, just to confirm how this should be done, the intel manual [1] states:
1) Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use1)
2) Issue XGETBV and verify that XCR0[2:1] = ‘11b’ (XMM state and YMM state are enabled by OS).
3) detect CPUID.1:ECX.AVX[bit 28] = 1 (AVX instructions supported).
(Step 3 can be done in any order relative to 1 and 2)

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462-rmver.html - section 13.5

(In reply to comment #6)
> @Jeff: I have access to a Xen system to test these issues, so if you post a
> link to the patch I can test.
> 
> Note that with the two original patches I still get issues in strcasecmp() with
> illegal instructions with AVX:
> 
> #0  0x00007ffff76cd0ff in __strcasecmp_l_avx () from ./lib/libc.so.6
> 
>    0x00007ffff76cd0f7 <+23>:    and    $0x3f,%rcx
>    0x00007ffff76cd0fb <+27>:    and    $0x3f,%rax
> => 0x00007ffff76cd0ff <+31>:    vmovdqa 0x46979(%rip),%xmm4        #
> 0x7ffff7713a80
>    0x00007ffff76cd107 <+39>:    vmovdqa 0x469a1(%rip),%xmm5        #
> 0x7ffff7713ab0
>    0x00007ffff76cd10f <+47>:    vmovdqa 0x46989(%rip),%xmm6        #
> 0x7ffff7713aa0
> 
> I will test with the additional patches linked in this bug report.
> 
> 
> BTW, just to confirm how this should be done, the intel manual [1] states:
> 1) Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use1)
> 2) Issue XGETBV and verify that XCR0[2:1] = ‘11b’ (XMM state and YMM state are
> enabled by OS).
> 3) detect CPUID.1:ECX.AVX[bit 28] = 1 (AVX instructions supported).
> (Step 3 can be done in any order relative to 1 and 2)
> 
> http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462-rmver.html
> - section 13.5

Can you test this?
http://sourceware.org/ml/libc-alpha/2012-05/msg00607.html

Allan, if you could test the patch referenced by Carlos in c#7, that'd be better than testing my hack.  

My hack (well actually Konrad's hack) is similar to what AJ posted on libc-alpha and resets cpu_features, which Carlos would like to avoid (and which I tend to agree is hackish).  We'll probably use my hack for f17 simply due to time constraints.  But for f18 and beyond Carlos's change or a variant thereof would be better.

I still get illegal instructions (vmovdqa) in __strcasecmp_l_avx () with Carlos' patch [1].  The patch from Andreas [2] works.

[1] http://sourceware.org/ml/libc-alpha/2012-05/msg00607.html
[2] http://sourceware.org/ml/libc-alpha/2012-05/msg00321.html

(Xen DomU, i7-2600, x86_64-unknown-linux-gnu)

Allan, please test:

http://sourceware.org/ml/libc-alpha/2012-05/msg00619.html

And let's continue this discussion on libc-alpha where I posted the patch.

Final fix is now on trunk.

http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=1a0994f5356214e8af8a1c1cc33fbf74a7ac8993

I will backport this to 2.15.

Backported final fix. Testing.

Checked into 2.15.