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 14:15:13 -0600 Message-ID: <4FAC21D1.4030005@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: > > 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