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

[Jeff Law <law@redhat.com>]

On 05/10/2012 06:58 PM, Konrad Rzeszutek Wilk wrote:
>>> 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.
>>
>> Sadly no as it would have executed the xgetv instruction. Since the first
>> part of the boolean logic returns false.
>
> <sigh>  And that is what I get from typing this while stopping at
> lights and being in a hurry and doing this on a cellphone.
> Please ignore what I said above - the earlier version would have worked correct.
No worries :-)

Had you not gotten involved, I never would have seen the xen-devel 
thread which then referred me to the appropriate Intel doc to confirm 
that your patch should fix the problem.  Your input on this issue has 
been greatly appreciated.

jeff