[PATCH 0/4] x86: update AMD CPUID bits

[PATCH 0/4] x86: update AMD CPUID bits

[Andre Przywara]

(resent to add kvm@vger)
Recently the public AMD CPUID specification
http://support.amd.com/us/Processor_TechDocs/25481.pdf
has been updated and revealed new CPUID flag feature names.
The following patches introduce them to the kernel to properly
display them in /proc/cpuinfo and allows KVM guests to use them.
Note: One bit has been renamed, so I propose patch 1/4 for inclusion
in the stable series.

Please apply!

Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

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

[Andre Przywara]

The AMD SSE5 feature set as-it has been replaced by some extensions
to the AVX instruction set. Thus the bit formerly advertised as SSE5
is re-used for one of these extensions (XOP).
Although this changes the /proc/cpuinfo output, it is not user visible, as
there are no CPUs (yet) having this feature.
To avoid confusion this should be added to the stable series, too.

Cc: stable@kernel.org [.32.x .34.x, .35.x]
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/cpufeature.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

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 */
-- 
1.6.4

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

[Avi Kivity]

  On 09/03/2010 12:27 PM, Andre Przywara wrote:
> The AMD SSE5 feature set as-it has been replaced by some extensions
> to the AVX instruction set. Thus the bit formerly advertised as SSE5
> is re-used for one of these extensions (XOP).
> Although this changes the /proc/cpuinfo output, it is not user visible, as
> there are no CPUs (yet) having this feature.
> To avoid confusion this should be added to the stable series, too.
>
>
>
> 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.

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

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

[Andre Przywara]

Avi Kivity wrote:
>   On 09/03/2010 12:27 PM, Andre Przywara wrote:
>> The AMD SSE5 feature set as-it has been replaced by some extensions
>> to the AVX instruction set. Thus the bit formerly advertised as SSE5
>> is re-used for one of these extensions (XOP).
>> Although this changes the /proc/cpuinfo output, it is not user visible, as
>> there are no CPUs (yet) having this feature.
>> To avoid confusion this should be added to the stable series, too.
>>
>>
>>
>> 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.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

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

[Avi Kivity]

  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

[PATCH 2/4] x86: Update AMD CPUID feature bits

[Andre Przywara]

AMD's public CPUID specification has been updated and some bits have
got names. Add them to properly describe new CPU features.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/cpufeature.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index c9c73d8..341835d 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -155,7 +155,11 @@
 #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_LWP		(6*32+15) /* Light Weight Profiling */
+#define X86_FEATURE_FMA4	(6*32+16) /* 4 operands MAC instructions */
 #define X86_FEATURE_NODEID_MSR	(6*32+19) /* NodeId MSR */
+#define X86_FEATURE_TBM		(6*32+21) /* trailing bit manipulations */
+#define X86_FEATURE_TOPOEXT	(6*32+22) /* topology extensions CPUID leafs */
 
 /*
  * Auxiliary flags: Linux defined - For features scattered in various
-- 
1.6.4

[PATCH 3/4] x86: Fix allowed CPUID bits for KVM guests

[Andre Przywara]

The AMD extension to AVX (FMA4, XOP) work on the same YMM register set
as AVX, so they are safe for guests to use, as long as AVX itself
is allowed.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/kvm/x86.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3a09c62..eb89e7b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1996,8 +1996,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	const u32 kvm_supported_word6_x86_features =
 		F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
 		F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
-		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(SSE5) |
-		0 /* SKINIT */ | 0 /* WDT */;
+		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
+		0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM);
 
 	/* all calls to cpuid_count() should be made on the same cpu */
 	get_cpu();
-- 
1.6.4

Re: [PATCH 3/4] x86: Fix allowed CPUID bits for KVM guests

[Avi Kivity]

  On 09/03/2010 12:27 PM, Andre Przywara wrote:
> The AMD extension to AVX (FMA4, XOP) work on the same YMM register set
> as AVX, so they are safe for guests to use, as long as AVX itself
> is allowed.
>
> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
> ---
>   arch/x86/kvm/x86.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 3a09c62..eb89e7b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1996,8 +1996,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>   	const u32 kvm_supported_word6_x86_features =
>   		F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
>   		F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
> -		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(SSE5) |
> -		0 /* SKINIT */ | 0 /* WDT */;
> +		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
> +		0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM);
>

Should be folded into patch 1 to avoid build breakage.

Did we really enable "sse5" before xsave?  That looks broken, but I 
guess no real harm if xsave itself is not enabled.

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

Re: [PATCH 3/4] x86: Fix allowed CPUID bits for KVM guests

[Andre Przywara]

Avi Kivity wrote:
>   On 09/03/2010 12:27 PM, Andre Przywara wrote:
>> The AMD extension to AVX (FMA4, XOP) work on the same YMM register set
>> as AVX, so they are safe for guests to use, as long as AVX itself
>> is allowed.
>>
>> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>> ---
>>   arch/x86/kvm/x86.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 3a09c62..eb89e7b 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1996,8 +1996,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>>   	const u32 kvm_supported_word6_x86_features =
>>   		F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
>>   		F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
>> -		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(SSE5) |
>> -		0 /* SKINIT */ | 0 /* WDT */;
>> +		F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
>> +		0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM);
>>
> 
> Should be folded into patch 1 to avoid build breakage.
Right you are. Thanks for spotting this. I fixed that and will sent out 
a version 2 later.
> 
> Did we really enable "sse5" before xsave?  That looks broken, but I 
> guess no real harm if xsave itself is not enabled.
Yes. It somehow slipped through when you introduced the other feature 
flags to KVM. I also think this is not a serious problem.
BTW: I realized that AES is currently denied. Reading the manual I see 
that it operates on SSE registers, so it should be safe to be passed 
through. The only drawback is that it would change the visible CPUID on 
CPUs that already have AES, whereas earlier KVM versions did hide it. 
This could become a problem with migration. But if you agree, I'd 
integrate this flag in the v2 series.

Regards,
Andre.



-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

Re: [PATCH 3/4] x86: Fix allowed CPUID bits for KVM guests

[Avi Kivity]

  On 09/06/2010 03:05 PM, Andre Przywara wrote:
>
>>
>> Did we really enable "sse5" before xsave?  That looks broken, but I 
>> guess no real harm if xsave itself is not enabled.
> Yes. It somehow slipped through when you introduced the other feature 
> flags to KVM. I also think this is not a serious problem.
> BTW: I realized that AES is currently denied. Reading the manual I see 
> that it operates on SSE registers, so it should be safe to be passed 
> through. The only drawback is that it would change the visible CPUID 
> on CPUs that already have AES, whereas earlier KVM versions did hide it.

This code doesn't directly affect a guest's cpuid, it merely tells host 
userspace which cpuid bits are supported by kvm.  It's perfectly fine to 
add bits as we add support, in fact this interface is what makes 
migration work across cpus with different capabilities.

> This could become a problem with migration. But if you agree, I'd 
> integrate this flag in the v2 series.

Shouldn't be a problem - please do.

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

[PATCH 4/4] x86, kvm: add new AMD SVM feature bits

[Andre Przywara]

The recently updated CPUID specification names new SVM feature bits.
Add them to the list of reported features.

Signed-off-by: Andre Przywara <andre.przywara@amd,com>
---
 arch/x86/include/asm/cpufeature.h |    7 +++++++
 arch/x86/kernel/cpu/scattered.c   |    6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 341835d..bffeab7 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -183,6 +183,13 @@
 #define X86_FEATURE_LBRV	(8*32+ 6) /* AMD LBR Virtualization support */
 #define X86_FEATURE_SVML	(8*32+ 7) /* "svm_lock" AMD SVM locking MSR */
 #define X86_FEATURE_NRIPS	(8*32+ 8) /* "nrip_save" AMD SVM next_rip save */
+#define X86_FEATURE_TSCRATEMSR  (8*32+ 9) /* "tsc_scale" AMD TSC scaling support */
+#define X86_FEATURE_VMCBCLEAN   (8*32+10) /* "vmcb_clean" AMD VMCB clean bits support */
+#define X86_FEATURE_FLUSHBYASID (8*32+11) /* AMD flush-by-ASID support */
+#define X86_FEATURE_DECODEASSISTS (8*32+12) /* AMD Decode Assists support */
+#define X86_FEATURE_PAUSEFILTER (8*32+13) /* AMD filtered pause intercept */
+#define X86_FEATURE_PFTHRESHOLD (8*32+14) /* AMD pause filter threshold */
+
 
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 9 */
 #define X86_FEATURE_FSGSBASE	(9*32+ 0) /* {RD/WR}{FS/GS}BASE instructions*/
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 34b4dad..2c77931 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -43,6 +43,12 @@ void __cpuinit init_scattered_cpuid_features(struct cpuinfo_x86 *c)
 		{ X86_FEATURE_LBRV,		CR_EDX, 1, 0x8000000a, 0 },
 		{ X86_FEATURE_SVML,		CR_EDX, 2, 0x8000000a, 0 },
 		{ X86_FEATURE_NRIPS,		CR_EDX, 3, 0x8000000a, 0 },
+		{ X86_FEATURE_TSCRATEMSR,	CR_EDX, 4, 0x8000000a, 0 },
+		{ X86_FEATURE_VMCBCLEAN,	CR_EDX, 5, 0x8000000a, 0 },
+		{ X86_FEATURE_FLUSHBYASID,	CR_EDX, 6, 0x8000000a, 0 },
+		{ X86_FEATURE_DECODEASSISTS,	CR_EDX, 7, 0x8000000a, 0 },
+		{ X86_FEATURE_PAUSEFILTER,	CR_EDX,10, 0x8000000a, 0 },
+		{ X86_FEATURE_PFTHRESHOLD,	CR_EDX,12, 0x8000000a, 0 },
 		{ 0, 0, 0, 0, 0 }
 	};
 
-- 
1.6.4

Re: [PATCH 0/4] x86: update AMD CPUID bits

[Avi Kivity]

  On 09/03/2010 12:27 PM, Andre Przywara wrote:
> (resent to add kvm@vger)

What about linux-kernel?  These patches should go in via the x86 tree.

> Recently the public AMD CPUID specification
> http://support.amd.com/us/Processor_TechDocs/25481.pdf
> has been updated and revealed new CPUID flag feature names.
> The following patches introduce them to the kernel to properly
> display them in /proc/cpuinfo and allows KVM guests to use them.
> Note: One bit has been renamed, so I propose patch 1/4 for inclusion
> in the stable series.
>

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

Re: [PATCH 0/4] x86: update AMD CPUID bits

[Avi Kivity]

  On 09/05/2010 11:07 AM, Avi Kivity wrote:
>  On 09/03/2010 12:27 PM, Andre Przywara wrote:
>> (resent to add kvm@vger)
>
> What about linux-kernel?  These patches should go in via the x86 tree.

Well, I guess I can carry them, but please copy x86@ and linux-kernel.

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

Re: [PATCH 0/4] x86: update AMD CPUID bits

[Andre Przywara]

Avi Kivity wrote:
>   On 09/05/2010 11:07 AM, Avi Kivity wrote:
>>  On 09/03/2010 12:27 PM, Andre Przywara wrote:
>>> (resent to add kvm@vger)
>> What about linux-kernel?  These patches should go in via the x86 tree.
> 
> Well, I guess I can carry them, but please copy x86@ and linux-kernel.
> 
I sent them out to linux-kernel and hpa/mingo/tglx before, but just 
forgot to copy kvm@vger. So I resent them again to kvm for review.
So you don't need to care about integrating them (I guess), I just 
wanted the feedback (you already gave).

Thanks,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

Re: [PATCH 0/4] x86: update AMD CPUID bits

[Avi Kivity]

  On 09/05/2010 06:10 PM, Andre Przywara wrote:
> Avi Kivity wrote:
>>   On 09/05/2010 11:07 AM, Avi Kivity wrote:
>>>  On 09/03/2010 12:27 PM, Andre Przywara wrote:
>>>> (resent to add kvm@vger)
>>> What about linux-kernel?  These patches should go in via the x86 tree.
>>
>> Well, I guess I can carry them, but please copy x86@ and linux-kernel.
>>
> I sent them out to linux-kernel and hpa/mingo/tglx before, but just 
> forgot to copy kvm@vger. So I resent them again to kvm for review.

Next time, please append the cc list, don't replace it, so everyone can 
see the comments.

> So you don't need to care about integrating them (I guess), I just 
> wanted the feedback (you already gave).

In general I like to carry patches that touch kvm files in kvm.git, so 
developers have just one base to work against.  For such small changes, 
it doesn't matter.

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