From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaZ9f-0000zZ-JP for qemu-devel@nongnu.org; Mon, 29 Feb 2016 20:31:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaZ9e-0003E3-60 for qemu-devel@nongnu.org; Mon, 29 Feb 2016 20:31:15 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:57886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaZ9d-0003Dl-Iv for qemu-devel@nongnu.org; Mon, 29 Feb 2016 20:31:14 -0500 Date: Tue, 1 Mar 2016 12:19:21 +1100 From: David Gibson Message-ID: <20160301011921.GI5427@voom.redhat.com> References: <20160218033952.GG15224@voom.fritz.box> <20160218113739.64b02461@nial.brq.redhat.com> <20160219043848.GZ15224@voom.fritz.box> <20160219164911.091b4351@nial.brq.redhat.com> <20160222025432.GD2808@voom.fritz.box> <20160223104645.6b64f60c@nial.brq.redhat.com> <20160223212620.GF3901@thinpad.lan.raisama.net> <20160224154218.5bd84960@nial.brq.redhat.com> <20160225175206.GE3313@thinpad.lan.raisama.net> <20160229164258.11e44bd5@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u/L2/WlOHZg+YGU4" Content-Disposition: inline In-Reply-To: <20160229164258.11e44bd5@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: lvivier@redhat.com, thuth@redhat.com, Peter Krempa , Eduardo Habkost , aik@ozlabs.ru, Markus Armbruster , qemu-devel@nongnu.org, agraf@suse.de, abologna@redhat.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, afaerber@suse.de --u/L2/WlOHZg+YGU4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 04:42:58PM +0100, Igor Mammedov wrote: > On Thu, 25 Feb 2016 14:52:06 -0300 > Eduardo Habkost wrote: >=20 > > On Wed, Feb 24, 2016 at 03:42:18PM +0100, Igor Mammedov wrote: > > > On Tue, 23 Feb 2016 18:26:20 -0300 > > > Eduardo Habkost wrote: > > > =20 > > > > On Tue, Feb 23, 2016 at 10:46:45AM +0100, Igor Mammedov wrote: =20 > > > > > On Mon, 22 Feb 2016 13:54:32 +1100 > > > > > David Gibson wrote: =20 > > > > [...] =20 > > > > > > This is why Eduardo suggested - and I agreed - that it's probab= ly > > > > > > better to implement the "1st layer" as an internal structure/in= terface > > > > > > only, and implement the 2nd layer on top of that. When/if we n= eed to > > > > > > we can revisit a user-accessible interface to the 1st layer. = =20 > > > > > We are going around QOM based CPU introspecting interface for > > > > > years now and that's exactly what 2nd layer is, just another > > > > > implementation. I've just lost hope in this approach. > > > > >=20 > > > > > What I'm suggesting in this RFC is to forget controversial > > > > > QOM approach for now and use -device/device_add + QMP introspecti= on, =20 > > > >=20 > > > > You have a point about it looking controversial, but I would like > > > > to understand why exactly it is controversial. Discussions seem > > > > to get stuck every single time we try to do something useful with > > > > the QOM tree, and I don't undertsand why. =20 > > > Maybe because we are trying to create a universal solution to fit > > > ALL platforms? And every time some one posts patches to show > > > implementation, it would break something in existing machine > > > or is not complete in terms of how interface would work wrt > > > mgmt/CLI/migration. =20 > >=20 > > That's true. > >=20 > > > =20 > > > > =20 > > > > > i.e. completely split interface from how boards internally implem= ent > > > > > CPU hotplug. =20 > > > >=20 > > > > A QOM-based interface may still split the interface from how > > > > boards internally implement CPU hotplug. They don't need to > > > > affect the device tree of the machine, we just need to create QOM > > > > objects or links at predictable paths, that implement certain > > > > interfaces. =20 > > > Beside of not being able to reach consensus for a long time, > > > I'm fine with isolated QOM interface if it allow us to move forward. > > > However static QMP/QAPI interface seems to be better describing and > > > has better documentation vs current very flexible poorly self-describ= ing QOM. =20 > >=20 > > You have a good point: QMP is more stable and better documented. > > QOM is easier for making experiments, and I would really like to > > see it being used more. But if we still don't understand the > > requirements enough to design a QMP interface, we won't be able > > to implement the same functionality using QOM either. > >=20 > > If we figure out the requirements, I believe we should be able to > > design equivalent QMP and QOM interfaces. > So not to stall CPU hotplug progress, I'd start with stable QMP query > interface for general use, leaving experimental QOM interface for later > as difficult to discover and poorly documented one from mgmt pov, > meaning mgmt would have to: > - instantiate a particular machine type to find if QOM interface is supp= orted, > i.e. '-machine none' won't work with it as it's board depended VS stat= ic compile time qapi-schema in QMP case > - execute a bunch of qom-list/qom-read requests over wire to enumerate/q= uery > objects starting at some fixed entry point (/machine/cpus) VS a single= command that does 'atomic' enumeration in QMP case. That sounds reasonable to me. However, before even that, I think we need to work out exactly what device_add of a multi-thread cpu module looks like. I think that's less of a solved problem than everyone seems to be assuming. --=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 --u/L2/WlOHZg+YGU4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW1O4ZAAoJEGw4ysog2bOS0fIQAJZB/8M1fQpOmrDyWjwQdSmm flMauSimFfI/zZ1OqW6gBvFKsMhbXucOMlCnuKdSqFuexH1ImlYp16z5wTvQe2ME QR2GBUgk9UsK5uwGKthRtj0gpxaKr+ZoXDQBi6vG5lbivsg8RPxvXzdfST/cohnk eG5kSbhZCG1QeSwEKn8j2+ANKcrkL0v7EGSa1cbsH37EfeopFg+Le19FmKJmE/am q6Mv74WhTvTXuEGve3D6OQxaiJKHjLBDD9TA3OGGUXMZfJ2c5O6A3+ygFniUZrWO L50Ppc7ORi3DBPDVrCVTdn5SbEDAryFXkciSPLBrqci9HVNgg8Fvuz6f9WyxOsB6 eugKRDZ1A1masPChlkNCkZ7cJvER42jzmnFtKEUzQN4lJxAsfJYrlAovO+DDuaVi U07gzg0+wolrYJS6NLilaFldo9OyWgUohN8aeNAliuwpAG7HHeEmA/VeaTsmxzND r76ao9e4gTYXSKd8BKXYJRw4pGoydkXO/9l/jES3Ixch7kBB/b8GgqgSN7B56/xD ivqI1gGdoKqKpVLWylAki3ihtMV3DePbfsbpQCjHiMTLVuu1f7yndQ6bPh4KOVWy pfZji+ujMJYJawWfLf7LojSGNWi19GF2D7bUKENbHlBS1Mdk/KC9h2ZUfjcy7Nz3 VCr540P4GnjGqKc0dNzq =HCnt -----END PGP SIGNATURE----- --u/L2/WlOHZg+YGU4--