[libvirt] [RFC] New CPU hotplug APIs

[Li Zhang]

On 2013年04月25日 20:22, Peter Krempa wrote:
> 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

Hi Peter,

I have some questions about the flags:

1. VIR_DOMAIN_VCPU_MAP_AGENT_OFFLINABLE
I think only CPU0 or BSP can't be offline on x86,
Other CPUs could be turned off,is it right?
For PowerPC, I have test and CPU0 can be turned off.

Is there any other consideration about this flag?

2. VIR_DOMAIN_VCPU_MAP_AGENT_ONLINABLE
I think all of offline CPUs can be turned on.
So VIR_DOMAIN_VCPU_MAP_AGENT_ONLINABLE can
be removed, IMHO. :)

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

Should be a parameter "cpumap" in this interface to be updated when 
VCPU's state is changed?
PowerPC can use this interface although it doesn't support ACPI.
But I think the implementation may be quite different.

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