Re: [PATCH 1/4] x86: Fix misnamed AMD CPUID feature bit

[Avi Kivity <avi@redhat.com>]

  On 09/05/2010 06:37 PM, Andre Przywara wrote:
>>> diff --git a/arch/x86/include/asm/cpufeature.h 
>>> b/arch/x86/include/asm/cpufeature.h
>>> index 781a50b..c9c73d8 100644
>>> --- a/arch/x86/include/asm/cpufeature.h
>>> +++ b/arch/x86/include/asm/cpufeature.h
>>> @@ -152,7 +152,7 @@
>>>   #define X86_FEATURE_3DNOWPREFETCH (6*32+ 8) /* 3DNow prefetch 
>>> instructions */
>>>   #define X86_FEATURE_OSVW    (6*32+ 9) /* OS Visible Workaround */
>>>   #define X86_FEATURE_IBS        (6*32+10) /* Instruction Based 
>>> Sampling */
>>> -#define X86_FEATURE_SSE5    (6*32+11) /* SSE-5 */
>>> +#define X86_FEATURE_XOP        (6*32+11) /* extended AVX 
>>> instructions */
>>>   #define X86_FEATURE_SKINIT    (6*32+12) /* SKINIT/STGI 
>>> instructions */
>>>   #define X86_FEATURE_WDT        (6*32+13) /* Watchdog timer */
>>>   #define X86_FEATURE_NODEID_MSR    (6*32+19) /* NodeId MSR */
>>
>> Even with the -stable update, there may be distributions which have 
>> kernels with the old name.  That means userspace would need to look 
>> for both names if it wants to be sure.
>
> CPUs having XOP will not be available before next year, and since XOP 
> is using the same register set as AVX, it cannot be used without 
> proper XSAVE/XRESTORE support. I am not sure when exactly XSAVE was 
> introduced in the kernel, but I think this limits the usability of 
> older kernels for XOP.
> I see that there is a faint possibility of causing trouble, but I 
> don't see any real alternative.

Perhaps it reduces trouble, since userspace can't conclude anything from 
seeing the sse5 or xop flag.  It needs to use a cpuid osxsave; xgetbv; 
cpuid xop to be sure it can actually use the instructions.

All that remains is user confusion, but I see no real alternative either.

-- 
error compiling committee.c: too many arguments to function