On Thu, Apr 18, 2013 at 12:00:09PM +0200, Peter Krempa wrote: > Hmm, okay that seems fair enough. The virDomainSetvcpus api has the > ideal name for this but mixing the semantics of disabling CPUs with > the angent and ripping them out from the hypervisor might lead to > user confusion. > > In this case we need to design a new API. Here are a few suggestions: > > 1) virDomainSetGuestVCPU(virDomainPtr dom, > unsigned int cpu_id, > bool state, > unsigned int flags); > > This api would be very easy for us as only one cpu could be modified > at time, thus no painful error reporting on semi-failed > transactions. Harder to use in mgmt apps as they would need to call > it multiple times. Yep, the simplicity is nice. I don't think it is much of a burden to apps. > 2) virDomainSetGuestVCPUs(virDomainPtr dom, > virBitmapPtr to_online, > virBitmapPtr to_offline, > unsigned int flags); > > Doesn't look very nice. Two bitmaps are needed as CPU indexes are > not guaranteed to be contiguous inside of a guest. Is easier to use > for mgmt apps as only a single call is needed. Libvirt will have to > solve failures and maybe even attempt rollback. More importantly I don't want us to expose virBitmapPtr in the public API ! We'd want to use raw bitmask as we do for other CPU related APIs > 3) virDomainSetGuestVCPUs(virDomainPtr dom, > virBitmapPtr cpumap, > bool state, > unsigned int flags); > > Variation of 2), one cpu map and a state flag that will determine > what action to take with the cpus provided in the map instead of two > separate maps. > > Other possibility would be to expose the cpu state in a kind of > array as the agent monitor functions do it right now, but this > wouldn't be expandable and would require users to use that new data > structure. > > Again, the getter functions will need to do the same, so that the > user will be able to obtain a map of the system to do decisions > about offlining and onlining processors. > > > In the future we will also need similar APIs for classic cpu hotplug > as qemu is probably going to support it in that way. With the > classic hotplug we probably won't need to take care of sparse cpu > ID's. > > Any other design or naming suggestions are welcome. Since 'cpu_id' in this refers to the guest OS' notion of CPUs, do we need some way to expose what the guest OS considers the CPU IDs to be. Personally I like the simpler first API, since it has easy to understand error behaviour. What is the data format QEMU agent requires for toggling CPUs ? Does it allow multiple CPUs to be changed at once ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list