[PATCH 2/2] hvm: allow pass-through of new CPUID features

[PATCH 2/2] hvm: allow pass-through of new CPUID features

[Andre Przywara]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Hi,

there are some new CPUID features that are safe for guests to see, as 
they don't require OS awareness (FPU/ALU related instructions only). 
Among features for new AMD CPUs there is also the PCLMULQDQ bit, which 
Intel CPU have already for quite a while.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Regards,
Andre.

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


[-- Attachment #2: cpuid_whitelist.patch --]
[-- Type: text/x-patch, Size: 4675 bytes --]

commit 9bef04464fa614566b154870261ffae7602571f4
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Wed Jan 26 11:50:55 2011 +0100

    extend CPUID whitelist to include new ALU/FPU only features

diff --git a/tools/libxc/xc_cpufeature.h b/tools/libxc/xc_cpufeature.h
index 07bdb95..5263774 100644
--- a/tools/libxc/xc_cpufeature.h
+++ b/tools/libxc/xc_cpufeature.h
@@ -83,6 +83,7 @@
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */
+#define X86_FEATURE_PCLMULQDQ	(4*32+ 1) /* Carry-less multiplication */
 #define X86_FEATURE_DTES64	(4*32+ 2) /* 64-bit Debug Store */
 #define X86_FEATURE_MWAIT	(4*32+ 3) /* Monitor/Mwait support */
 #define X86_FEATURE_DSCPL	(4*32+ 4) /* CPL Qualified Debug Store */
@@ -104,6 +105,7 @@
 #define X86_FEATURE_AES		(4*32+25) /* AES acceleration instructions */
 #define X86_FEATURE_XSAVE	(4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */
 #define X86_FEATURE_AVX		(4*32+28) /* Advanced Vector Extensions */
+#define X86_FEATURE_F16C	(4*32+29) /* Half-precision convert instruction */
 #define X86_FEATURE_HYPERVISOR	(4*32+31) /* Running under some hypervisor */
 
 /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 407a535..150ca18 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -101,7 +101,10 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM) |
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
-                    bitmaskof(X86_FEATURE_3DNOWPREFETCH));
+                    bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_XOP) |
+                    bitmaskof(X86_FEATURE_FMA4) |
+                    bitmaskof(X86_FEATURE_TBM));
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
@@ -251,12 +254,14 @@ static void xc_cpuid_hvm_policy(
         regs[1] = (regs[1] & 0x0000ffffu) | ((regs[1] & 0x007f0000u) << 1);
 
         regs[2] &= (bitmaskof(X86_FEATURE_XMM3) |
+                    bitmaskof(X86_FEATURE_PCLMULQDQ) |
                     bitmaskof(X86_FEATURE_SSSE3) |
                     bitmaskof(X86_FEATURE_CX16) |
                     bitmaskof(X86_FEATURE_SSE4_1) |
                     bitmaskof(X86_FEATURE_SSE4_2) |
                     bitmaskof(X86_FEATURE_POPCNT) |
                     bitmaskof(X86_FEATURE_AES) |
+                    bitmaskof(X86_FEATURE_F16C) |
                     ((xfeature_mask != 0) ?
                      (bitmaskof(X86_FEATURE_AVX) |
                       bitmaskof(X86_FEATURE_XSAVE)) : 0));
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 1634802..5c591f6 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -115,6 +115,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
         {"dscpl",        0x00000001, NA, CPUID_REG_ECX,  4,  1},
         {"monitor",      0x00000001, NA, CPUID_REG_ECX,  3,  1},
         {"dtes64",       0x00000001, NA, CPUID_REG_ECX,  2,  1},
+        {"pclmulqdq",    0x00000001, NA, CPUID_REG_ECX,  1,  1},
         {"sse3",         0x00000001, NA, CPUID_REG_ECX,  0,  1},
         {"pbe",          0x00000001, NA, CPUID_REG_EDX, 31,  1},
         {"ia64",         0x00000001, NA, CPUID_REG_EDX, 30,  1},
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 8d9b49d..9b783ad 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -82,6 +82,7 @@
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */
+#define X86_FEATURE_PCLMULQDQ	(4*32+ 1) /* Carry-less mulitplication */
 #define X86_FEATURE_DTES64	(4*32+ 2) /* 64-bit Debug Store */
 #define X86_FEATURE_MWAIT	(4*32+ 3) /* Monitor/Mwait support */
 #define X86_FEATURE_DSCPL	(4*32+ 4) /* CPL Qualified Debug Store */
@@ -103,6 +104,7 @@
 #define X86_FEATURE_XSAVE	(4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */
 #define X86_FEATURE_OSXSAVE	(4*32+27) /* OSXSAVE */
 #define X86_FEATURE_AVX 	(4*32+28) /* Advanced Vector Extensions */
+#define X86_FEATURE_F16C 	(4*32+29) /* Half-precision convert instruction */
 #define X86_FEATURE_HYPERVISOR	(4*32+31) /* Running under some hypervisor */
 
 /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Ian Jackson]

Andre Przywara writes ("[Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
> there are some new CPUID features that are safe for guests to see, as 
> they don't require OS awareness (FPU/ALU related instructions only). 
> Among features for new AMD CPUs there is also the PCLMULQDQ bit, which 
> Intel CPU have already for quite a while.

This would seem to be a new feature.  We are currently in feature
freeze.

Can you make a justification for a freeze exception ?

Ian.

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Andre Przywara]

Ian Jackson wrote:
> Andre Przywara writes ("[Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
>> there are some new CPUID features that are safe for guests to see, as 
>> they don't require OS awareness (FPU/ALU related instructions only). 
>> Among features for new AMD CPUs there is also the PCLMULQDQ bit, which 
>> Intel CPU have already for quite a while.
> 
> This would seem to be a new feature.
I agree to some point, although (at least in respect to PCLMULQDQ) I'd 
consider this more as "forgotten enablement".

 > We are currently in feature freeze.
> 
> Can you make a justification for a freeze exception ?
If you can make me believe that it does not take another year until this 
shows up in an official release, then I am totally fine with skipping 4.1.0.
What is the policy regarding the 4.1.x releases? Have features like 
those a chance of being applied?

Regards,
Andre.

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

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Stefano Stabellini]

On Thu, 27 Jan 2011, Andre Przywara wrote:
> Ian Jackson wrote:
> > Andre Przywara writes ("[Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
> >> there are some new CPUID features that are safe for guests to see, as 
> >> they don't require OS awareness (FPU/ALU related instructions only). 
> >> Among features for new AMD CPUs there is also the PCLMULQDQ bit, which 
> >> Intel CPU have already for quite a while.
> > 
> > This would seem to be a new feature.
> I agree to some point, although (at least in respect to PCLMULQDQ) I'd 
> consider this more as "forgotten enablement".
> 
>  > We are currently in feature freeze.
> > 
> > Can you make a justification for a freeze exception ?
> If you can make me believe that it does not take another year until this 
> shows up in an official release, then I am totally fine with skipping 4.1.0.
> What is the policy regarding the 4.1.x releases? Have features like 
> those a chance of being applied?

I think Ian was just looking for a well written explanation of why we
need this now :)

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
> I think Ian was just looking for a well written explanation of why we
> need this now :)

Yes, and particularly, a clear explanation of why applying this now
will not break things.

That would justify making an exception to the freeze with a clear
conscience :-).

Ian.

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Andre Przywara]

Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
>> I think Ian was just looking for a well written explanation of why we
>> need this now :)
OK, I feel challenged, what about this:

The new CPU features are pure "compute" features (ALU/FPU only), they 
don't need any support or awareness from any system level software. 
Following the definition of virtualization they should be available to 
guests unless explicitly disabled.
The AES feature was introduced at the same time as the PCLMULQDQ 
feature, AES is passed through, PCLMULQDQ has obviously been forgotten(?).
The Linux kernel uses both instructions in newer versions for optimized 
cryptographic algorithms implementation 
(arch/x86/crypto/ghash-clmulni-intel_asm.S)
The current version of the Xen hypervisor would deny this feature to any 
PV domains, including Dom0, leaving systems running under Xen with an 
inferior cryptographic performance.
This patch allows PV domains to use the feature to get on par with 
systems running with other virtualization software.

Regards,
Andre.


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

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Andre Przywara]

Andre Przywara wrote:
> Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
>>> I think Ian was just looking for a well written explanation of why we
>>> need this now :)
> OK, I feel challenged, what about this:
> 
> The new CPU features are pure "compute" features (ALU/FPU only), they 
> don't need any support or awareness from any system level software. 
> Following the definition of virtualization they should be available to 
> guests unless explicitly disabled.
> The AES feature was introduced at the same time as the PCLMULQDQ 
> feature, AES is passed through, PCLMULQDQ has obviously been forgotten(?).
> The Linux kernel uses both instructions in newer versions for optimized 
> cryptographic algorithms implementation 
> (arch/x86/crypto/ghash-clmulni-intel_asm.S)


> The current version of the Xen hypervisor would deny this feature to any 
> PV domains, including Dom0, leaving systems running under Xen with an 
> inferior cryptographic performance.
> This patch allows PV domains to use the feature to get on par with 
> systems running with other virtualization software.

Seems like I was a bit to eager with my rationale, this patch of course 
affects only HVM guests.

Regards,
Andre.

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

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Ian Jackson]

Andre Przywara writes ("Re: [Xen-devel] [PATCH 2/2] hvm: allow pass-through of new CPUID features"):
> Andre Przywara wrote:
> > The new CPU features are pure "compute" features (ALU/FPU only), they 
> > don't need any support or awareness from any system level software. 
> > Following the definition of virtualization they should be available to 
> > guests unless explicitly disabled.

Thanks for that explanation.  Can you confirm that these features
don't involve new CPU state ?  If so then I'm happy that they should
go in despite the freeze.

Regards,
Ian.

Re: [PATCH 2/2] hvm: allow pass-through of new CPUID features

[Keir Fraser]

On 27/01/2011 15:43, "Andre Przywara" <andre.przywara@amd.com> wrote:

> Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 2/2] hvm: allow
>> pass-through of new CPUID features"):
>>> I think Ian was just looking for a well written explanation of why we
>>> need this now :)
> OK, I feel challenged, what about this:
> 
> The new CPU features are pure "compute" features (ALU/FPU only), they
> don't need any support or awareness from any system level software.
> Following the definition of virtualization they should be available to
> guests unless explicitly disabled.
> The AES feature was introduced at the same time as the PCLMULQDQ
> feature, AES is passed through, PCLMULQDQ has obviously been forgotten(?).
> The Linux kernel uses both instructions in newer versions for optimized
> cryptographic algorithms implementation
> (arch/x86/crypto/ghash-clmulni-intel_asm.S)
> The current version of the Xen hypervisor would deny this feature to any
> PV domains, including Dom0, leaving systems running under Xen with an
> inferior cryptographic performance.
> This patch allows PV domains to use the feature to get on par with
> systems running with other virtualization software.

You've lost your mind a bit there. The patch affects only HVM guests. PV
guests have a feature blacklist policy, and so these features are already
passed through to PV guests (inc. dom0) just fine.

 -- Keir

> Regards,
> Andre.
>