[libvirt] [PATCH 19/27] conf: Add XML for individual vCPU hotplug

[Pavel Hrdina]

On Wed, Aug 17, 2016 at 01:45:18PM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 17, 2016 at 02:42:21PM +0200, Peter Krempa wrote:
> > On Fri, Aug 12, 2016 at 10:29:53 +0200, Pavel Hrdina wrote:
> > > On Fri, Aug 05, 2016 at 03:56:15PM +0200, Peter Krempa wrote:
> > > > Individual vCPU hotplug requires us to track the state of any vCPU. To
> > > > allow this add the following XML:
> > > > 
> > > > <domain>
> > > >   ...
> > > >   <vcpu current='1'>2</vcpu>
> > > >   <vcpus>
> > > >     <vcpu id='0' enabled='no' hotpluggable='yes'/>
> > > >     <vcpu id='1' enabled='yes' hotpluggable='no' order='1'/>
> > > >   </vcpus>
> > > >   ...
> > > > 
> > > > The 'enabled' attribute allows to control the state of the vcpu.
> > > > 'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
> > > > allows to specify the order to add the vcpus.
> > > 
> > > Based on CPU arch there are some restriction how many vcpus must be plugged in
> > > together, currently only for Power arch.  Based on configured topology we can
> > 
> > Yep. I admit though that the documentation is pretty weak since I wanted
> > to get review started. I plan to add more of it though.
> > 
> > > plug only whole cores, which means group of vcpus.  Because of this I would
> > > suggest that we group those vcpus in the XML like this:
> > > 
> > >     <vcpus>
> > >       <group id='1' enabled='yes' hotpluggable='no' order='1'>
> > >         <vcpu id='0'/>
> > >         <vcpu id='1'/>
> > >       </group>
> > 
> > I don't think this is a good idea:
> > 
> > 1) This XML part is not input-only thus users will need to provide this
> >    (also see below)
> > 
> > 2) it's extremely verbose for non-weird architectures
> >    granted, for ppc64 it allows to display the wiredness of the
> >    core-level hotplug, but for x86 it's 3 times more verbose
> > 
> >    on the off-hand it requires the user to provide this in advance an
> > 
> > 3) this does not hide the weirdness of the "hotpluggable entities" as
> >    reported by qemu.
> > 
> >    With this we basically could add the vcpus to <devices>. At the
> >    'group' granularity which would be basically a dumb wrapper on top of
> >    the qemu design.
> > 
> > 4) It can't be properly verified at define time.
> >    (okay, my approach can't be validated either, but it's vastly
> >    simpler and more tolerant to config changes)
> 
> Agree to all those points.
> 
> IMHO the domain capabilities is the place where we should expose
> any information about the ppc-specific pre-requisite rules for
> vcpus and hotplug. Apps should consume the capabilities and then
> format domain XML in a "normal" syntax, honouring the constraints
> expressed in the capabilities.

Yes those points are valid and it makes sense.  My main motivation was to
discuss the XML design before I'll continue with review.

Pavel