Re: [Qemu-devel] [PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge

[Eduardo Habkost]

[CCing Daniel]

On Tue, Jan 16, 2018 at 04:33:00PM +0100, Kashyap Chamarthy wrote:
> On Tue, Jan 16, 2018 at 01:55:22PM +0100, Vincent Bernat wrote:
> >  ❦ 16 janvier 2018 10:41 -0200, Eduardo Habkost <address@hidden> :
> > 
> > >> > 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.

I still don't understand why OpenStack doesn't let users add or
modify elements on the domain XML.  This isn't the first time I
see this preventing users from fixing problems or optimizing
their systems.

Is there a summary of the reasons behind this limitation
somewhere?

-- 
Eduardo