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 :|