qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-ppc] [RFC PATCH v0 0/6] Core based CPU hotplug for PowerPC sPAPR


From: Bharata B Rao
Subject: [Qemu-ppc] [RFC PATCH v0 0/6] Core based CPU hotplug for PowerPC sPAPR
Date: Thu, 25 Feb 2016 21:52:36 +0530

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]