[libvirt] [RFC] New CPU hotplug APIs

[Peter Krempa]

Hi upstream,

I'd like to discuss the design of CPU modification related APIs before I 
start working on them.

Qemu recently added support for modification of the state of the cpu 
using the guest agent and is also doing work on hot plug of cpus and 
possibly even hot unplug.

This stuff will require us to introduce new APIs to take full advantage 
of the new code for qemu.

I'm imagining adding 3 new API functions: 1 universal getter function 
and 2 specific setters: one for agent based modifications and one for 
classic (ACPI) cpu hotplug.

1) The getter function:

int
virDomainGetVCPUMap(virDomainPtr dom,
	            const char **cpumap,
		    unsigned int flags);

With no flags, this function would return the map of online CPUs in the 
guest.

The flags will allow us then to do:
VIR_DOMAIN_VCPU_MAP_AGENT_ONLINE - map of online cpus as the guest agent 
sees it
VIR_DOMAIN_VCPU_MAP_AGENT_OFFLINABLE - map of online cpus that can be 
turned off
VIR_DOMAIN_VCPU_MAP_AGENT_ONLINABLE - map of offline cpus that can be 
turned on
VIR_DOMAIN_VCPU_MAP_AGENT_POSSIBLE - all vcpus as the guest agent sees them
(_AGENT_OFFLINE probably isn't useful

And similarly for offline processors:
VIR_DOMAIN_VCPU_MAP_ONLINE
VIR_DOMAIN_VCPU_MAP_ONLINABLE
VIR_DOMAIN_VCPU_MAP_POSSIBLE
(no idea if offlinable makes sense here)

The universal nature of this function would be documented right away and 
would save us having separate getters for agent based hotplug and 
classic one.

The returned map would be automatically allocated and the length of it 
returned as the return value.

This getter will allow us representing (possibly) sparse allocation of 
the cpu IDs.

2) Setters

int
virDomainSetVCPUState(virDomainPtr dom,
		      int id,
                       bool state,
                       unsigned int flags);
for classic CPU hotplug and:

virDomainSetGuestVCPUState(virDomainPtr dom,
			   int id,
                            bool state,
                            unsigned int flags);
for agent based cpu offlining.

This will represent the setter functions with similar semantics. I've 
gone for two to absolutely differentiate the agent based stuff from the 
classic one, but they could be merged into a single one with appropriate 
flags).

These will allow modification of state of single CPUs so that errors can 
be handled gracefully. The id corresponds to position of the bit in the 
cpumap requested by the getter func described above.

Thanks in advance for your input on this design stuff.

Peter