Andreas Färber <afaer...@suse.de> writes: > Am 16.02.2016 um 13:35 schrieb Markus Armbruster: >> Igor Mammedov <imamm...@redhat.com> writes: >> >>> On Mon, 15 Feb 2016 20:43:41 +0100 >>> Markus Armbruster <arm...@redhat.com> 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? >>> Do you mean generic QOM introspection? >> >> Possibly, but I don't want to prematurely limit the conversation to 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 >> >> Encoding information in names feels wrong. >> >>> 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. >> >> I acknowledge your concern regarding QOM tree stability. We have QOM >> introspection commands since 1.2. They make the QOM tree part of the >> external interface, but we've never spelled out which parts of it (if >> any) are ABI. Until we do, parts become de facto ABI by being used in >> anger. As a result, we don't know something's ABI until it breaks. >> >> Andreas, do you have an opinion on proper use of QOM by external >> software? > > This is absolutely untrue, there have been ABI rules in place and I held > a presentation covering them in 2012...
I stand corrected! Got a pointer to the current ABI rules?