From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Law Subject: Re: xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. Date: Thu, 10 May 2012 13:39:53 -0600 Message-ID: <4FAC1989.4060201@redhat.com> References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120509173836.GB9094@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, haitao.shan@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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. That doesn't make sense to me given the text under availability and support here: http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/ According to my reading AVX can only be used if the hardware supports AVX *and* the OS supports XSAVE. The only weasel language is "To use the Intel AVX extensions reliably in most settings ..." Which Uli might be relying upon for his position. Ironically, the code in init-arch used to look like: if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) { /* Reset the AVX bit in case OSXSAVE is disabled. */ if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSXSAVE) == 0 || ({ unsigned int xcrlow; unsigned int xcrhigh; asm ("xgetbv" : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); (xcrlow & 6) != 6; })) __cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ~bit_AVX; } Which I think would have done the right thing. Uli changed it to the form you quoted just 2 hours after installing the version I quoted. If i'm going to make the claim Uli is wrong, some clarification from Intel would be appreciated. jeff