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

[Jan-Frode Myklebust]

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