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