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