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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
