[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.

Jiri Denemark jdenemar at redhat.com
Wed Oct 8 07:49:35 UTC 2014


On Tue, Oct 07, 2014 at 21:22:12 +0200, Jan-Frode Myklebust wrote:
> 
> Signed-off-by: Jan-Frode Myklebust <janfrode at 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




More information about the libvir-list mailing list