[libvirt] [PATCH] "pclmuldq" was introduced with Westmere, not Sandy Bridge. This feature is important to get proper performance for aes-128-gcm in openssl, an important cipher for https communication.
2:22 p.m.
Signed-off-by: Jan-Frode Myklebust <janfrode(a)tanso.net>
---
src/cpu/cpu_map.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 18c7b0d..94f1458 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -488,11 +488,11 @@
<model name='Westmere'>
<model name='Nehalem'/>
<feature name='aes'/>
+ <feature name='pclmuldq'/>
</model>
<model name='SandyBridge'>
<model name='Westmere'/>
- <feature name='pclmuldq'/>
<feature name='x2apic'/>
<feature name='tsc-deadline'/>
<feature name='xsave'/>
--
1.7.1
3:15 p.m.
Just some documentation for the fact that this was introduced with
Westmere:
https://software.intel.com/sites/default/files/managed/72/cc/clmul-wp-rev...
"Intel® PCLMULQDQ instruction is a new instruction available
beginning with the all new 2010 Intel® Core™ processor family based on
the 32nm Intel® microarchitecture codename Westmere"
https://en.wikipedia.org/wiki/CLMUL_instruction_set
"Carry-less Multiplication (CLMUL) is an extension to the x86
instruction set used by microprocessors from Intel and AMD which was
proposed by Intel in March 2008[1] and made available in the Intel
Westmere processors announced in early 2010."
https://en.wikipedia.org/wiki/Westmere_%28microarchitecture%29
"Delivers seven new instructions (AES instruction set or AES-NI)
that will be used by the AES algorithm. Also an instruction called
PCLMULQDQ (see CLMUL instruction set) that will perform carry-less
multiplication for use in cryptography."
-jf
2:49 a.m.
On Tue, Oct 07, 2014 at 21:22:12 +0200, Jan-Frode Myklebust wrote:
Signed-off-by: Jan-Frode Myklebust <janfrode(a)tanso.net>
---
src/cpu/cpu_map.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 18c7b0d..94f1458 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -488,11 +488,11 @@
<model name='Westmere'>
<model name='Nehalem'/>
<feature name='aes'/>
+ <feature name='pclmuldq'/>
</model>
<model name='SandyBridge'>
<model name='Westmere'/>
- <feature name='pclmuldq'/>
<feature name='x2apic'/>
<feature name='tsc-deadline'/>
<feature name='xsave'/>
Technically you are correct and even QEMU added this feature to Westmere
in April 2013. However, our goal is to provide stable virtual hardware
that doesn't change when, e.g., a domain is migrated to another machine
(let's ignore the fact we don't currently enforce such stability for CPU
models/features because of missing functionality in both QEMU and
libvirt). Thus we should not really change existing CPU models. We may
be able to do that in the future depending how (if ever) we solve the
CPU definition probing in QEMU and how libvirt will make use of it to
really enforce stable ABI for guest operating systems.
Moreover, it's trivial to enable the feature in domain XML:
<cpu mode='custom' match='exact'>
<model fallback='forbid'>Westmere</model>
<feature policy='require' name='pclmuldq'/>
</cpu>
That said, I don't think we should take this patch, at least not for
now.
Jirka
5:28 a.m.
On Wed, Oct 08, 2014 at 09:49:35AM +0200, Jiri Denemark wrote:
Technically you are correct and even QEMU added this feature to Westmere
in April 2013. However, our goal is to provide stable virtual hardware
that doesn't change when, e.g., a domain is migrated to another machine
(let's ignore the fact we don't currently enforce such stability for CPU
models/features because of missing functionality in both QEMU and
libvirt). Thus we should not really change existing CPU models. We may
be able to do that in the future depending how (if ever) we solve the
CPU definition probing in QEMU and how libvirt will make use of it to
really enforce stable ABI for guest operating systems.
Right, I see the problem, but am having a bit trouble accepting that all
our 20 RHEV-H westmere hypervisors are basicly downgraded to nehalem
feature-set permanently because if this, and we probably have to live
with these servers for quite some time. If you can't fix existing virtual
cpu types, maybe you should add a "westmere-full-feature" cpu type, or
similar? And probably also add "rdtscp" which also is missing from the
virtual westmere.
Moreover, it's trivial to enable the feature in domain XML:
We're using RHEV, and RHEV-H on all hypervisors, so not so easy to fix
for us.. Have opened ticket with Red Hat for this.
-jf
5:59 a.m.
On 10/14/2014 01:28 PM, Jan-Frode Myklebust wrote:
On Wed, Oct 08, 2014 at 09:49:35AM +0200, Jiri Denemark wrote:
>
> Technically you are correct and even QEMU added this feature to Westmere
> in April 2013. However, our goal is to provide stable virtual hardware
> that doesn't change when, e.g., a domain is migrated to another machine
> (let's ignore the fact we don't currently enforce such stability for CPU
> models/features because of missing functionality in both QEMU and
> libvirt). Thus we should not really change existing CPU models. We may
> be able to do that in the future depending how (if ever) we solve the
> CPU definition probing in QEMU and how libvirt will make use of it to
> really enforce stable ABI for guest operating systems.
Right, I see the problem, but am having a bit trouble accepting that all
our 20 RHEV-H westmere hypervisors are basicly downgraded to nehalem
feature-set permanently because if this, and we probably have to live
with these servers for quite some time. If you can't fix existing virtual
cpu types, maybe you should add a "westmere-full-feature" cpu type, or
similar? And probably also add "rdtscp" which also is missing from the
virtual westmere.
if libvirt would change the definition, then a mixed cluster (old and
new libvirt) would be broken. it will only work if its a new cpu model
>
> Moreover, it's trivial to enable the feature in domain XML:
>
We're using RHEV, and RHEV-H on all hypervisors, so not so easy to fix
for us.. Have opened ticket with Red Hat for this.
you can edit the RHEV config at per OS level or cluster level to edit
the cpu (not sure the global change this will persist after an upgrade).
-jf
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
6:02 a.m.
On Tue, Oct 14, 2014 at 01:59:15PM +0300, Itamar Heim wrote:
On 10/14/2014 01:28 PM, Jan-Frode Myklebust wrote:
>On Wed, Oct 08, 2014 at 09:49:35AM +0200, Jiri Denemark wrote:
>>
>>Technically you are correct and even QEMU added this feature to Westmere
>>in April 2013. However, our goal is to provide stable virtual hardware
>>that doesn't change when, e.g., a domain is migrated to another machine
>>(let's ignore the fact we don't currently enforce such stability for CPU
>>models/features because of missing functionality in both QEMU and
>>libvirt). Thus we should not really change existing CPU models. We may
>>be able to do that in the future depending how (if ever) we solve the
>>CPU definition probing in QEMU and how libvirt will make use of it to
>>really enforce stable ABI for guest operating systems.
>
>
>Right, I see the problem, but am having a bit trouble accepting that all
>our 20 RHEV-H westmere hypervisors are basicly downgraded to nehalem
>feature-set permanently because if this, and we probably have to live
>with these servers for quite some time. If you can't fix existing virtual
>cpu types, maybe you should add a "westmere-full-feature" cpu type, or
>similar? And probably also add "rdtscp" which also is missing from the
>virtual westmere.
if libvirt would change the definition, then a mixed cluster (old and new
libvirt) would be broken. it will only work if its a new cpu model
Management apps aren't restricted to using an exact CPU model. They are
free to turn on/off extra features relative to the CPU model's bultin
features. So using 'rdtscp' doesn't require libvirt to provide a new
CPU model - RHEV can just add <feature name='rdtscp'/> to the XML it
sends to libvirt if it wants to. Of course you need to consider cross
node compat when doing so still.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
3692
days inactive
3699
days old
5 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Itamar Heim -
Jan-Frode Myklebust -
Jiri Denemark