Re: [libvirt] [RFC] New CPU hotplug APIs
On 05/02/13 11:13, Peter Krempa wrote: On 04/25/13 14: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. Qemu now also committed classic cpu hotplug support using the cpu_add command, so this RFC is now even more relevant. Anybody having opinions on this? Ping? Qemu just pulled the cpu_add patches, and they will release it in 1.5. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] New CPU hotplug APIs
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] New CPU hotplug APIs
On 04/25/13 14: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. Qemu now also committed classic cpu hotplug support using the cpu_add command, so this RFC is now even more relevant. Anybody having opinions on this? Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] New CPU hotplug APIs
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
