Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus

[Igor Mammedov]

On Mon, 15 Feb 2016 20:43:41 +0100
Markus Armbruster <address@hidden> wrote:

> Igor Mammedov <address@hidden> writes:
> 
> > it will allow mgmt to query present and possible to hotplug CPUs
> > it is required from a target platform that wish to support
> > command to set board specific MachineClass.possible_cpus() hook,
> > which will return a list of possible CPUs with options
> > that would be needed for hotplugging possible CPUs.
> >
> > For RFC there are:
> >    'arch_id': 'int' - mandatory unique CPU number,
> >                       for x86 it's APIC ID for ARM it's MPIDR
> >    'type': 'str' - CPU object type for usage with device_add
> >
> > and a set of optional fields that would allows mgmt tools
> > to know at what granularity and where a new CPU could be
> > hotplugged;
> > [node],[socket],[core],[thread]
> > Hopefully that should cover needs for CPU hotplug porposes for
> > magor targets and we can extend structure in future adding
> > more fields if it will be needed.
> >
> > also for present CPUs there is a 'cpu_link' field which
> > would allow mgmt inspect whatever object/abstraction
> > the target platform considers as CPU object.
> >
> > For RFC purposes implements only for x86 target so far.  
> 
> Adding ad hoc queries as we go won't scale.  Could this be solved by a
> generic introspection interface?
Do you mean generic QOM introspection?

Using QOM we could have '/cpus' container and create QOM links
for exiting (populated links) and possible (empty links) CPUs.
However in that case link's name will need have a special format
that will convey an information necessary for mgmt to hotplug
a CPU object, at least:
  - where: [node],[socket],[core],[thread] options
  - optionally what CPU object to use with device_add command

Another approach to do QOM introspection would be to model hierarchy 
of objects like node/socket/core..., That's what Andreas
worked on. Only it still suffers the same issue as above
wrt introspection and hotplug, One can pre-create empty
[nodes][sockets[cores]] containers at startup but then
leaf nodes that could be hotplugged would be a links anyway
and then again we need to give them special formatted names
(not well documented at that mgmt could make sense of).
That hierarchy would need to become stable ABI once
mgmt will start using it and QOM tree is quite unstable
now for that. For some targets it involves creating dummy
containers like node/socket/core for x86 where just modeling
a thread is sufficient.

The similar but a bit more abstract approach was suggested
by David https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg00000.html

Benefit of dedicated CPU hotplug focused QMP command is that
it can be quite abstract to suite most targets and not depend
on how a target models CPUs internally and still provide
information needed for hotplugging a CPU object.
That way we can split efforts on how we model/refactor CPUs
internally and how mgmt would work with them using
-device/device_add.