From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYPTm-000846-Px for qemu-devel@nongnu.org; Tue, 23 Feb 2016 21:47:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYPTl-0007dr-8B for qemu-devel@nongnu.org; Tue, 23 Feb 2016 21:47:06 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:52312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYPTk-0007cY-L5 for qemu-devel@nongnu.org; Tue, 23 Feb 2016 21:47:05 -0500 Date: Wed, 24 Feb 2016 12:57:11 +1100 From: David Gibson Message-ID: <20160224015711.GG2808@voom.fritz.box> References: <1455556228-232720-1-git-send-email-imammedo@redhat.com> <878u2lhi8i.fsf@blackfin.pond.sub.org> <20160216113655.2bbb9988@nial.brq.redhat.com> <20160218033952.GG15224@voom.fritz.box> <20160218113739.64b02461@nial.brq.redhat.com> <20160219043848.GZ15224@voom.fritz.box> <87h9h5uiy8.fsf@blackfin.pond.sub.org> <20160222023228.GC2808@voom.fritz.box> <87h9h1i07h.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BNd1cQq+8a6XQVk/" Content-Disposition: inline In-Reply-To: <87h9h1i07h.fsf@blackfin.pond.sub.org> 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 Cc: lvivier@redhat.com, thuth@redhat.com, ehabkost@redhat.com, Igor Mammedov , aik@ozlabs.ru, qemu-devel@nongnu.org, agraf@suse.de, abologna@redhat.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, afaerber@suse.de --BNd1cQq+8a6XQVk/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 22, 2016 at 10:05:54AM +0100, Markus Armbruster wrote: > David Gibson writes: >=20 > > On Fri, Feb 19, 2016 at 10:51:11AM +0100, Markus Armbruster wrote: > >> David Gibson writes: > >>=20 > >> > On Thu, Feb 18, 2016 at 11:37:39AM +0100, Igor Mammedov wrote: > >> >> On Thu, 18 Feb 2016 14:39:52 +1100 > >> >> David Gibson wrote: > >> >>=20 > >> >> > On Tue, Feb 16, 2016 at 11:36:55AM +0100, Igor Mammedov wrote: > >> >> > > On Mon, 15 Feb 2016 20:43:41 +0100 > >> >> > > Markus Armbruster wrote: > >> >> > > =20 > >> >> > > > Igor Mammedov writes: > >> >> > > > =20 > >> >> > > > > 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 MPI= DR > >> >> > > > > '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 > >> >> > > >=20 > >> >> > > > Adding ad hoc queries as we go won't scale. Could this be so= lved by a > >> >> > > > generic introspection interface? =20 > >> >> > > Do you mean generic 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 > >> >> >=20 > >> >> > Hmm.. is it not enough to follow the link and get the topology > >> >> > information by examining the target? > >> >> One can't follow a link if it's an empty one, hence > >> >> CPU placement information should be provided somehow, > >> >> either: > >> > > >> > Ah, right, so the issue is determining the socket/core/thread > >> > addresses that cpus which aren't yet present will have. > >> > > >> >> * by precreating cpu-package objects with properties that > >> >> would describe it /could be inspected via OQM/ > >> > > >> > So, we could do this, but I think the natural way would be to have t= he > >> > information for each potential thread in the package. Just putting > >> > say "core number" in the package itself assumes more than I'd like > >> > about how packages sit in the heirarchy. Plus, it means that > >> > management has a bunch of cases to deal with: package has all the > >> > information, package has just a core id, package has just a socket i= d, > >> > and so forth. > >> > > >> > It is a but clunky that when the package is plugged, this information > >> > will have to sit parallel to the array of actual thread links. > >> > > >> > Markus or Andreas is there a natural way to present a list of (node, > >> > socket, core, thread) tuples in the package object? Preferably > >> > without having to create a whole bunch of "potential thread" objects > >> > just for the purpose. > >>=20 > >> I'm just a dabbler when it comes to QOM, but I can try. > >>=20 > >> I view a concrete cpu-package device (subtype of the abstract > >> cpu-package device) as a composite device containing stuff like actual > >> cores. > > > > So.. the idea is it's a bit more abstract than that. My intention is > > that the package lists - in some manner - each of the threads > > (i.e. vcpus) it contains / can contain. Depending on the platform it > > *might* also have internal structure such as cores / sockets, but it > > doesn't have to. Either way, the contained threads will be listed in > > a common way, as a flat array. > > > >> To create a composite device, you start with the outer shell, then plug > >> in components one by one. Components can be nested arbitrarily deep. > >>=20 > >> Perhaps you can define the concrete cpu-package shell in a way that le= ts > >> you query what you need to know from a mere shell (no components > >> plugged). > > > > Right.. that's exactly what I'm suggesting, but I don't know enough > > about the presentation of basic data in QOM to know quite how to > > accomplish it. > > > >> >> or > >> >> * via QMP/HMP command that would provide the same information > >> >> only without need to precreate anything. The only difference > >> >> is that it allows to use -device/device_add for new CPUs. > >> > > >> > I'd be ok with that option as well. I'd be thinking it would be > >> > implemented via a class method on the package object which returns t= he > >> > addresses that its contained threads will have, whether or not they'= re > >> > present right now. Does that make sense? > >>=20 > >> If you model CPU packages as composite cpu-package devices, then you > >> should be able to plug and unplug these with device_add, unless pluggi= ng > >> them requires complex wiring that can't be done in qdev / device_add, > >> yet. > > > > There's a whole bunch of issues raised by allowing device_add of > > cpus. Although they're certainly interesting and probably useful, I'd > > really like to punt on them for the time being, so we can get some > > sort of cpu hotplug working on Power (and s390 and others). >=20 > If you make it a device, you can still set > cannot_instantiate_with_device_add_yet to disable -device / device_add > for now, and unset it later, when you're ready for it. Yes, that was the plan. > > The idea of the cpu packages is that - at least for now - the user > > can't control their contents apart from the single "present" bit. > > They already know what they can contain. >=20 > Composite devices commonly do. They're not general containers. >=20 > The "present" bit sounds like you propose to "pre-plug" all the possible > CPU packages, and thus reduce CPU hot plug/unplug to enabling/disabling > pre-plugged CPU packages. Yes. > What if a board can take different kinds of CPU packages? Do we > pre-plug all combinations? Then some combinations are non-sensical. > How would we reject them? I'm not trying to solve all cases with the present bit handling - just the currently common case of a machine with fixed maximum number of slots which are expected to contain identical processor units. > For instance, PC machines support a wide range of CPUs in various > arrangements, but you generally need to use a single kind of CPU, and > the kind of CPU restricts the possible arrangements. How would you > model that? The idea is that the available slots are determined by the machine, possibly using machine or global options. So for PC, -cpu and -smp would determine the number of slots and what can go into them. > > There are a bunch of potential use cases this doesn't address, but I > > think it *does* address a useful subset of currently interesting > > cases, without precluding more flexible extensions in future. > > > >> If that's the case, a general solution for "device needs complex wirin= g" > >> would be more useful than a one-off for CPU packages. > >>=20 > >> [...] > >>=20 >=20 --=20 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 --BNd1cQq+8a6XQVk/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWzQ33AAoJEGw4ysog2bOSDskQAK+bFVbOhYfmHQDuftNdK16T GCLlXlmbb1A/2eJ8meQCAe2XRW0GJsVi8o7bEkiY0BNYkVUQ/A2QvrhaBwKETUlS JQfhsnGN8BeqW02i4H0sWbA5sdwlOeNoups3JZLJBpkzXQ/O1TWFsiBey/N2ZCTP kl0uCFGL2TeJf1MsWqCa+AS7T/RycNbyuiLWk4kX6L56lzbXr2E94vx8EC5G6iJE DfAsgPr2v3idtoCYy/C2vIgsrsRktum4CE08quFC6pMkkBu0rQ/b59NgLE+xfKAp UXdKNmSroBKn1xmwfKl65mJWEm2xAPkLiUzR+ikGOeX7rXQ51aOiU0ezw1ZROaCF Nev3FudyP6b7fb5b+2P18a36CaJzzxF/eR4mc6yynIY9gV86Xz68yUXT65N5SN8b /9n0fYBkpbKOqbquq1+dlk+oYi/0b9dtHlXYfjeQ8KBnXi/oHaPZINbQNhxhq+Aj KPXMPIA41H402Ox0yJ3JtCbEVSpFDiqJOgGDLpgliuydwFzJBTSiS7JaInhs8p74 HaCS3J4TmfjfYrG3g5mobsypgrC5got9e6keY0w1g61mnwCdQMkIlASSBkzTMtlO FpsSkb8A3+e0h5Dj1pagtOqqO2bmD8t+ZYtPhnSBfQAjsC6dx+OAzCnM4/MHpMW7 HP3uZPBK7cBYHB/eF3Sk =k3ql -----END PGP SIGNATURE----- --BNd1cQq+8a6XQVk/--