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 -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list