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