From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYyh0-0004QI-Pv for qemu-devel@nongnu.org; Thu, 25 Feb 2016 11:23:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYygv-0004PR-3b for qemu-devel@nongnu.org; Thu, 25 Feb 2016 11:23:06 -0500 Received: from e28smtp03.in.ibm.com ([125.16.236.3]:59775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYygu-0004Os-3t for qemu-devel@nongnu.org; Thu, 25 Feb 2016 11:23:01 -0500 Received: from localhost by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 25 Feb 2016 21:52:55 +0530 From: Bharata B Rao Date: Thu, 25 Feb 2016 21:52:36 +0530 Message-Id: <1456417362-20652-1-git-send-email-bharata@linux.vnet.ibm.com> Subject: [Qemu-devel] [RFC PATCH v0 0/6] Core based CPU hotplug for PowerPC sPAPR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: mjrosato@linux.vnet.ibm.com, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, Bharata B Rao , armbru@redhat.com, agraf@suse.de, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, pbonzini@redhat.com, imammedo@redhat.com, mdroth@linux.vnet.ibm.com, afaerber@suse.de, david@gibson.dropbear.id.au Hi, This is an attempt to implement CPU hotplug for PowerPC sPAPR based on the approach suggested by Andreas. While I say that, I should also explicitly add that I have tried to follow Andreas' suggestions to the best of my understanding and hence there could be bits which are still not as per expectations. I have tried to model this similarly to what Andreas did for x86 an year back at https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg04858.html - Base type to represent CPU core static const TypeInfo cpu_core_type_info = { .name = TYPE_CPU_CORE, .parent = TYPE_DEVICE, .abstract = true, }; This is similar to the abstract socket device type that Andreas created - sPAPR specific CPU core device static const TypeInfo spapr_cpu_core_type_info = { .name = TYPE_SPAPR_CPU_CORE, .parent = TYPE_CPU_CORE, .instance_init = spapr_cpu_core_instance_init, .instance_size = sizeof(sPAPRCPUCore), .class_init = spapr_cpu_core_class_init, }; This is similar to TYPE_X86_CPU_SOCKET that Andreas created to represent the x86 specifc CPU socket. - QOM links from machine object to CPU objects Target machine determines the hotplug granularity. Granularity is "core" for PowerPC. MacineClass:init() would create as many "core" links as necessary to span the max_cpus. The links are set for all the boot CPU cores from machine init. For rest of the cores, the links are left dangling and will be set during hotplug. The link essentially indicates or represents the CPU slots present on the board. The link name is used to identify the slot. In case of PowerPC, standard link names like core[0], core[1] etc will be used. Archs that work at socket granularity could use link names like socket[0] etc. sPAPR core device will have a property called "slot" which will be used to determine to which slot the core will get plugged into. Users are expected to use existing link names like core[0] etc as the values for slot property of the core device. Command to hotplug will look like this: (qemu) device_add spapr_cpu_core,id=core2,slot=core[2] - Creation of thread objects from core. It is ideal to create the thread objects from core object's instance_init. However thread object creation needs two inputs: number of threads and cpu_model. If we want to stick to the global values for these (smp_threads and MachineState.cpu_model), then we already know how many threads of what type to create in core's instance_init. However, if we want to be flexible and support heterogenous configuration in future, nr_threads and cpu_model can be made properties of core device and the CPU threads can be created from core object's property setters. While this implementation defines these two properties to obtain nr_threads and cpu_model, heterogenous configurations aren't allowed. sPAPR core device looks like this: typedef struct sPAPRCPUCore { /*< private >*/ DeviceState parent_obj; /*< public >*/ int nr_threads; char *cpu_model; char *slot; PowerPCCPU *threads; } sPAPRCPUCore; @nr_threads, @cpu_model and @slot get set as properties during device_add of spapr_cpu_core device. (qemu) device_add spapr_cpu_core,id=core2,nr_threads=8,cpu_model=host,slot=core[2] This will result in a core with 8 threads of cpu_model "host" getting created and the resulting core will populate the pre-existing slot "core[2]. @threads will be g_malloc'ed to contain @nr_threads from property setter. @cpu_model along with the base CPU type of powerpc64-cpu will be used to create the actual PowerPCCPU threads. So we will have CPU types like host-powerpc64-cpu or POWER8-powerpc64-cpu etc. - QMP interface The layout that I have in this implementation is more or less what Igor has implemented/suggested. MachineClass:cpu_slots() will be main interface to collect CPU slot information. Target machine can implement them to provide information about slots. What sits in the slot (core, socket or thread) is determined by the machine. { 'struct': 'CPUInfo', 'data': { 'arch-id': 'int', 'type': 'str', '*thread': 'int', '*core': 'int', '*socket' : 'int', '*node' : 'int', '*qom-path': 'str' } } { 'struct': 'CPUSlotInfo', 'data': { '*id': 'str', 'type': 'str', 'hotplug-granularity' : 'str', 'slot-id' : 'str', '*qom-path': 'str', 'realized': 'bool', '*nr-cpus': 'int', '*cpus' : ['CPUInfo'] } } The slot links that we created from machine object will serve as the starting point to get the information about available CPU slots and their occupancy status. We can walk the link properties of the machine object, and extract information about "core" links for PowerPC. Each CPU slot will provide the following information: Slot name/ID: core[0] etc for PowerPC hotplug_granularity: "core" for PowerPC (Probably not required) type: "spapr-cpu-core" for sPAPR realized: true/false indicating if the slot is populated or not I feel, the above information should be enough for the management to come up with an appropriate device_add command to create and fill a core into an empty slot. If the slot is populated, the following additional information is provided: qom_path: QOM path of the core (PowerPC) device nr_cpus: Number of CPUs that are part of this slot Each CPU will then have: Type, Arch ID, Thread ID, Core ID, Socket ID, NUMA node. This patchset is present at: https://github.com/bharata/qemu/commits/spapr-cpu-core Bharata B Rao (6): cpu: Abstract CPU core type spapr: CPU core device spapr: Represent boot CPUs as spapr-cpu-core devices spapr: CPU hotplug support qmp,spapr: Show hot-plugged/pluggable CPU slots in the Machine hmp: Implement 'info cpu-slots' hmp-commands-info.hx | 14 ++ hmp.c | 56 ++++++++ hmp.h | 1 + hw/core/machine.c | 19 +++ hw/cpu/Makefile.objs | 1 + hw/cpu/core.c | 22 +++ hw/ppc/Makefile.objs | 1 + hw/ppc/spapr.c | 311 ++++++++++++++++++++++++++++++++++++++-- hw/ppc/spapr_cpu_core.c | 210 +++++++++++++++++++++++++++ hw/ppc/spapr_events.c | 3 + hw/ppc/spapr_rtas.c | 24 ++++ include/hw/boards.h | 4 + include/hw/cpu/core.h | 17 +++ include/hw/ppc/spapr.h | 4 + include/hw/ppc/spapr_cpu_core.h | 32 +++++ qapi-schema.json | 85 +++++++++++ qmp-commands.hx | 47 ++++++ 17 files changed, 843 insertions(+), 8 deletions(-) create mode 100644 hw/cpu/core.c create mode 100644 hw/ppc/spapr_cpu_core.c create mode 100644 include/hw/cpu/core.h create mode 100644 include/hw/ppc/spapr_cpu_core.h -- 2.1.0