From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVewM-0001yi-FV for qemu-devel@nongnu.org; Tue, 16 Feb 2016 07:41:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVewH-0003OO-D8 for qemu-devel@nongnu.org; Tue, 16 Feb 2016 07:41:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:56002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVewG-0003JU-Qx for qemu-devel@nongnu.org; Tue, 16 Feb 2016 07:41:09 -0500 References: <1455556228-232720-1-git-send-email-imammedo@redhat.com> <878u2lhi8i.fsf@blackfin.pond.sub.org> <20160216113655.2bbb9988@nial.brq.redhat.com> <87y4aksuht.fsf@blackfin.pond.sub.org> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <56C318E1.1070500@suse.de> Date: Tue, 16 Feb 2016 13:41:05 +0100 MIME-Version: 1.0 In-Reply-To: <87y4aksuht.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Igor Mammedov Cc: lvivier@redhat.com, thuth@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, abologna@redhat.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, David Gibson , david@gibson.dropbear.id.au Am 16.02.2016 um 13:35 schrieb Markus Armbruster: > Igor Mammedov writes: >=20 >> On Mon, 15 Feb 2016 20:43:41 +0100 >> Markus Armbruster wrote: >> >>> Igor Mammedov 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. =20 >>> >>> 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? >=20 > Possibly, but I don't want to prematurely limit the conversation to QOM > introspection. >=20 >> 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 >=20 > Encoding information in names feels wrong. >=20 >> Another approach to do QOM introspection would be to model hierarchy=20 >> 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. >=20 > 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. >=20 > 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... Andreas >=20 >> The similar but a bit more abstract approach was suggested >> by David https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg00000.= html >=20 > Cc'ing him. If I understand the high-level idea correctly, David > proposes to have an abstract type cpu-package with generic properties. > Its concrete subtypes are composed of whatever components make up the > hot-pluggable unit. >=20 > Management software can then use the generic properties to deal with ho= t > plug without having to know about the concrete subtypes, at least to > some useful degree. >=20 > Similarly, the generic properties suffice for implementing generic > high-level interfaces like -smp. >=20 > David, is that a fair summary? >=20 > Naturally, we need a way to introspect available subtypes of cpu-packag= e > to answer questions like what concrete types can actually be plugged > into this board. >=20 > This could be an instance of the generic QOM introspection question > "what can plug into this socket"? Unfortunately, I don't know enough > QOM to put that into more concrete terms. Andreas, Paolo, can you help > out? >=20 >> 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. >=20 > CPUs might be special enough to warrant special commands. Nevertheless= , > non-special solutions should be at least explored. That's what we're > doing here. >=20 --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)