On Tue, 16 Feb 2016 16:48:34 +1100 David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Mon, Feb 15, 2016 at 08:43:41PM +0100, Markus Armbruster wrote: > > Igor Mammedov <imamm...@redhat.com> 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]"} ]}