On Tue, Jan 16, 2018 at 01:55:22PM +0100, Vincent Bernat wrote: > ❦ 16 janvier 2018 10:41 -0200, Eduardo Habkost <ehabk...@redhat.com> : > > >> > Adding Westmere-PCID would require adding a Westmere-PCID-IBRS > >> > CPU model too, so this is starting to look a bit ridiculous. > >> > Sane VM management systems would know how to use > >> > "-cpu Westmere,+pcid" without requiring new CPU model entries in > >> > QEMU. What's missing in existing management stacks to allow that > >> > to happen? > >> > >> That's what I actually do. So, I am fine with the solution of doing > >> nothing. However, it would be nice for unaware people to get the speedup > >> of pcid without knowing about it. Maybe we can just forget about > >> Westmere and still apply it to Sandy Bridge and Ivy Bridge. > > > > If management stacks today don't let the user choose > > "Westmere,+pcid", we probably have no other choice than adding a > > Westmere-PCID CPU model. But our management stacks need to be > > fixed so we won't need similar hacks in the future.
True; I'm aware of the limitation here in Nova. > With libvirt: > > <cpu mode='custom' match='exact'> > <model>Westmere</model> > <feature policy='require' name='pcid'/> > </cpu> Yep, libvirt upstream allows it. > We are using CloudStack on top of that and it's also an available > option. However, looking at OpenStack, it doesn't seem possible: > > https://github.com/openstack/nova/blob/6b248518da794a4c82665c22abf7bee5aa527a47/nova/conf/libvirt.py#L506 That's correct, upstream OpenStack Nova doesn't yet have facility to specify granular CPU feature names. Nova just ought to wire up the facility libvirt already provides. -- /kashyap
