[Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests
This patchset enables CPU and memory hotplug support for PowerPC guests. Changes in this patchset (v1): - Based on top of Michael Roth's tree (https://github.com/mdroth/qemu/commits/spapr-hotplug-core) which serves as base for his PCI hotplug patches too. - Switched to device_add/del semantics instead of cpu-add. - Supporting CPU hot unplug now. - Added patches to enable memory hotplug. - Added ibm,dynamic-reconfiguration-memory support which is needed for memory hotplug. v0 - http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00752.html CPU hotplug --- - Works with BE guest, has issues with LE guest. Has been tested on BE host only. - Adding a core (and all its threads) in response to device_add command. Similarly removing a core via device_del will remove all the threads. - Using Gu Zheng's "reclaim vCPU objects" patch to remove and reuse the vCPU objects after CPUs removal. (Gu Zheng's original patch: http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01829.html) Memory hotplug -- - Able to get an LMB added with the current patchset, but there are issues which I am still debugging. - Re-using pc-dimm infrastructure (hw/mem/pc-dimm.c) to support memory hotplug on PowerPC. - Tested with Nathan Fontenot's memory hotplug kernel patches (with additions to drive memory hotplug from EPOW interrupt path) (https://www.marc.info/?l=linuxppc-embedded&m=141626066317143&w=2) Bharata B Rao (11): spapr: Add DRC dt entries for CPUs spapr: Consider max_cpus during xics initialization spapr: Factor out CPU initialization code into realizefn spapr: Support ibm,lrdr-capacity device tree property spapr: CPU hotplug support spapr: Start all the threads of CPU core when core is hotplugged spapr: Enable CPU hotplug for POWER8 CPU family spapr: CPU hot unplug support spapr: Initialize hotplug memory address space spapr: Support ibm,dynamic-reconfiguration-memory spapr: Memory hotplug support Gu Zheng (1): cpus, spapr: reclaim allocated vCPU objects Michael Roth (1): spapr: enable PHB/CPU/LMB hotplug for pseries-2.3 cpus.c| 44 +++ default-configs/ppc64-softmmu.mak | 1 + hw/ppc/spapr.c| 744 ++ hw/ppc/spapr_events.c | 11 +- hw/ppc/spapr_hcall.c | 51 ++- hw/ppc/spapr_rtas.c | 28 +- include/hw/ppc/spapr.h| 27 +- include/qom/cpu.h | 11 + include/sysemu/kvm.h | 1 + kvm-all.c | 57 ++- target-ppc/translate_init.c | 50 ++- 11 files changed, 918 insertions(+), 107 deletions(-) -- 2.1.0
Re: [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests
Hi, Am 08.01.2015 um 07:10 schrieb Bharata B Rao: > This patchset enables CPU and memory hotplug support for PowerPC guests. > > Changes in this patchset (v1): > > - Based on top of Michael Roth's tree > (https://github.com/mdroth/qemu/commits/spapr-hotplug-core) which serves > as base for his PCI hotplug patches too. > - Switched to device_add/del semantics instead of cpu-add. Please don't forget to CC me on this. As previously discussed with Jason and Christian for s390x, there's certain topology modeling questions still unsolved for device-based QOM CPU hot-plug. I have an RFC in the works (again) that hopefully gets us a step closer. > - Supporting CPU hot unplug now. > - Added patches to enable memory hotplug. > - Added ibm,dynamic-reconfiguration-memory support which is needed for > memory hotplug. > > v0 - http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00752.html > > CPU hotplug > --- > - Works with BE guest, has issues with LE guest. Has been tested on BE host > only. > - Adding a core (and all its threads) in response to device_add command. > Similarly removing a core via device_del will remove all the threads. Earlier discussions concluded that hot-plug needs to happen on a socket level, not core. If you're assuming the socket to have one core (as we were planning for s390x), that doesn't make much of a difference number-wise, but it does in modeling terms. Think what you can physically plug onto the mainboard, that's the granularity that realized=true/false is going to operate on. A virtual socket may well correspond to a thread on some socket/node of the host, but you cannot add threads to a core or cores to a chip at runtime. On x86 this may become a functional limitation of what is possible through cpu-add, so better avoid that mistake for ppc from the start. Regards, Andreas > - Using Gu Zheng's "reclaim vCPU objects" patch to remove and reuse > the vCPU objects after CPUs removal. > (Gu Zheng's original patch: >http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01829.html) [snip] -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests
On 01/07/2015 10:10 PM, Bharata B Rao wrote: > This patchset enables CPU and memory hotplug support for PowerPC guests. I missed seeing this as the qemu-ppc list was not included. Can you please add myself and Nathan on Cc in the future as well. Tyrel > > Changes in this patchset (v1): > > - Based on top of Michael Roth's tree > (https://github.com/mdroth/qemu/commits/spapr-hotplug-core) which serves > as base for his PCI hotplug patches too. > - Switched to device_add/del semantics instead of cpu-add. > - Supporting CPU hot unplug now. > - Added patches to enable memory hotplug. > - Added ibm,dynamic-reconfiguration-memory support which is needed for > memory hotplug. > > v0 - http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00752.html > > CPU hotplug > --- > - Works with BE guest, has issues with LE guest. Has been tested on BE host > only. > - Adding a core (and all its threads) in response to device_add command. > Similarly removing a core via device_del will remove all the threads. > - Using Gu Zheng's "reclaim vCPU objects" patch to remove and reuse > the vCPU objects after CPUs removal. > (Gu Zheng's original patch: >http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01829.html) > > Memory hotplug > -- > - Able to get an LMB added with the current patchset, but there are issues > which I am still debugging. > - Re-using pc-dimm infrastructure (hw/mem/pc-dimm.c) to support memory > hotplug on PowerPC. > - Tested with Nathan Fontenot's memory hotplug kernel patches (with additions > to drive memory hotplug from EPOW interrupt path) > (https://www.marc.info/?l=linuxppc-embedded&m=141626066317143&w=2) > > Bharata B Rao (11): > spapr: Add DRC dt entries for CPUs > spapr: Consider max_cpus during xics initialization > spapr: Factor out CPU initialization code into realizefn > spapr: Support ibm,lrdr-capacity device tree property > spapr: CPU hotplug support > spapr: Start all the threads of CPU core when core is hotplugged > spapr: Enable CPU hotplug for POWER8 CPU family > spapr: CPU hot unplug support > spapr: Initialize hotplug memory address space > spapr: Support ibm,dynamic-reconfiguration-memory > spapr: Memory hotplug support > > Gu Zheng (1): > cpus, spapr: reclaim allocated vCPU objects > > Michael Roth (1): > spapr: enable PHB/CPU/LMB hotplug for pseries-2.3 > > cpus.c| 44 +++ > default-configs/ppc64-softmmu.mak | 1 + > hw/ppc/spapr.c| 744 > ++ > hw/ppc/spapr_events.c | 11 +- > hw/ppc/spapr_hcall.c | 51 ++- > hw/ppc/spapr_rtas.c | 28 +- > include/hw/ppc/spapr.h| 27 +- > include/qom/cpu.h | 11 + > include/sysemu/kvm.h | 1 + > kvm-all.c | 57 ++- > target-ppc/translate_init.c | 50 ++- > 11 files changed, 918 insertions(+), 107 deletions(-) >
Re: [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests
On Thu, Jan 29, 2015 at 06:46:30PM +0100, Andreas Färber wrote: > Hi, > > Am 08.01.2015 um 07:10 schrieb Bharata B Rao: > > This patchset enables CPU and memory hotplug support for PowerPC guests. > > > > Changes in this patchset (v1): > > > > - Based on top of Michael Roth's tree > > (https://github.com/mdroth/qemu/commits/spapr-hotplug-core) which serves > > as base for his PCI hotplug patches too. > > - Switched to device_add/del semantics instead of cpu-add. > > Please don't forget to CC me on this. As previously discussed with Jason > and Christian for s390x, there's certain topology modeling questions > still unsolved for device-based QOM CPU hot-plug. I have an RFC in the > works (again) that hopefully gets us a step closer. I think you are referring to this discussion: http://lists.gnu.org/archive/html/qemu-devel/2013-09/msg00778.html Looking forward to your above mentioned RFC. > > > - Supporting CPU hot unplug now. > > - Added patches to enable memory hotplug. > > - Added ibm,dynamic-reconfiguration-memory support which is needed for > > memory hotplug. > > > > v0 - http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00752.html > > > > CPU hotplug > > --- > > - Works with BE guest, has issues with LE guest. Has been tested on BE host > > only. > > - Adding a core (and all its threads) in response to device_add command. > > Similarly removing a core via device_del will remove all the threads. > > Earlier discussions concluded that hot-plug needs to happen on a socket > level, not core. If you're assuming the socket to have one core (as we > were planning for s390x), that doesn't make much of a difference > number-wise, but it does in modeling terms. Think what you can > physically plug onto the mainboard, that's the granularity that > realized=true/false is going to operate on. A virtual socket may well > correspond to a thread on some socket/node of the host, but you cannot > add threads to a core or cores to a chip at runtime. In PowerPC, guests conform to PAPR specifications and hence the hotplug behaviour with the real hardware will not matter. For pseries guests we add CPUs in core granularity. By default if we don't specify sockets= explicitly, the guest comes with as many sockets as there are cores with 1 core per socket. However we can have a guest that has multiple cores in a socket too. Hence if you have a CPU hotplug model where a socket is added at a time, I can't see any issues of supporting that with PowerPC hotplug. Based on the existing topology, we could hotplug as many cores in the socket as needed. However I would like to hear from others who understand PowerPC architecture to see if there are any caveats with this model. Regards, Bharata.