[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus |
Date: |
Wed, 17 Feb 2016 18:59:25 -0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Feb 16, 2016 at 11:36:55AM +0100, Igor Mammedov wrote:
> 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.
At the thread above, I suggested adding the concept of "CPU slot"
objects in the QOM tree, that wouldn't impose any restrictions in
the way the CPU packages/cores/thread objects themselves are
modelled in each machine+architecture.
It would be possible to provide exactly the same functionality
through new QMP commands. But I slightly prefer a QOM-based
interface, that seems more flexible than specialized QMP
commands. It would make it easier to provide extra information to
clients when necessary, and implement more powerful QOM-based
functionality later.
--
Eduardo
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, (continued)
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 <=
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/17
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Igor Mammedov, 2016/02/18
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/18
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Markus Armbruster, 2016/02/19
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Igor Mammedov, 2016/02/19
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/21
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Markus Armbruster, 2016/02/22
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/23
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Markus Armbruster, 2016/02/24
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/24