[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus |
Date: |
Thu, 18 Feb 2016 15:05:10 +1100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Feb 16, 2016 at 11:52:42AM +0100, Igor Mammedov wrote:
> On Tue, 16 Feb 2016 16:48:34 +1100
> David Gibson <address@hidden> wrote:
>
> > On Mon, Feb 15, 2016 at 08:43:41PM +0100, Markus Armbruster 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?
> >
> > That's my main concern as well.
> >
> > Igor, did you see my post with a proposal for how to organize
> > hotpluggable packages of CPUs? I believe that would also solve the
> > problem at hand here, by having a standard QOM location with
> > discoverable cpu objects.
> >
> > The interface in your patch in particular would *not* solve the
> > problem of advertising to management layers what the granularity of
> > CPU hotplug is, which we absolutely need for Power.
> I've had in mind Power as well, as topology items are optional
> a query can respond with what granularity board would like
> to use and what type of object it could be hotplugged:
>
> -> { "execute": "query-hotpluggable-cpus" }
> <- {"return": [
> {"core": 2, "socket": 2, "arch_id": 2, "type": "power-foo-core-cpu"},
> {"core": 1, "socket": 1, "arch_id": 1, "type": "power-foo-core-cpu"},
> {"core": 0, "socket": 0, "arch_id": 0, "type": "power-foo-core-cpu",
> "cpu_link": "/machine/unattached/device[3]"}
> ]}
Hrm.. except your arch_id is supplied by a CPUClass hook, making it a
per-thread property, whereas here it needs to be per-core.
Other than that I guess this covers what we need for Power, however I
dislike the idea of typing the hotplug granularity to be at any fixed
level of the socket/core/thread heirarchy. As noted elsewhere, while
all machines are likely to have some sort of similar heirarchy, giving
it fixed levels of "socket", "core" and "thread" may be limiting.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Igor Mammedov, 2016/02/16
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/17
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Markus Armbruster, 2016/02/18
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Eduardo Habkost, 2016/02/17