From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS4lu-00016N-AU for qemu-devel@nongnu.org; Mon, 24 Mar 2014 09:19:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS4fs-0007CE-JP for qemu-devel@nongnu.org; Mon, 24 Mar 2014 09:12:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS4fs-0007C5-Ad for qemu-devel@nongnu.org; Mon, 24 Mar 2014 09:12:20 -0400 Date: Mon, 24 Mar 2014 15:12:22 +0200 From: "Michael S. Tsirkin" Message-ID: <20140324131222.GA15065@redhat.com> References: <1395327676-29753-1-git-send-email-imammedo@redhat.com> <1395327676-29753-5-git-send-email-imammedo@redhat.com> <532B1361.9070006@redhat.com> <20140320172032.796a2974@nial.usersys.redhat.com> <532B2D8D.4040508@redhat.com> <20140321113541.1a5e7a96@nial.usersys.redhat.com> <5330231E.1030200@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5330231E.1030200@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 4/8] qdev: link based hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: marcel.a@redhat.com, qemu-devel@nongnu.org, vasilis.liaskovitis@profitbricks.com, aliguori@amazon.com, Paolo Bonzini , Igor Mammedov On Mon, Mar 24, 2014 at 01:20:46PM +0100, Andreas F=E4rber wrote: > Am 21.03.2014 11:35, schrieb Igor Mammedov: > > BTW not related to hotplug but why I used link<>s: > >=20 > > I've added link<>s as an attempt to visualize Andreas' idea to use th= em for >=20 > Anthony's :) >=20 > > hotplug and mgmt. It has it's own benefits if we try to provide more = or > > less uniform QOM interface view for management. What I have in mind i= s that > > we could have tree like this: > > /machine/node[...]/dimm[...] > > /cpu[...]/core[...]/thread[...] > >=20 > > where leaves are link<>s which are prebuilt at startup and set when d= evice > > is added. It provides an easy to enumerate interface for mgmt and als= o > > gives us a quite informative path that encodes topology and later > > we could use it instead of custom properties. For example: > >=20 > > device_add x86cpu,path=3D/machine/node[1]/cpu[0]/core[3]/thread[2] > > vs > > device_add x86cpu,apic-id=3D[who knows how it's calculated] >=20 > This still collides with what Anthony and me have been saying about CPU > hot-add: It should not happen on thread level. cpu-add covers the > current approach, but device_add should add a full socket and definitel= y > not in that /machine/node[n]/... path. You or someone replied on Paolo'= s > NUMA thread that this was only as an internal convenience for lookups, > now you're pushing this as user ABI. NACK to the latter. >=20 > I was hoping that we could let device_add auto-discover free link<> > slots like it does for buses today; That's friendly for HMP but a huge maintainance pain. In the end hardly anyone uses HMP for hotplug so I don't think there's a lot of value in auto-discovery, make management as explicit as possible. > having two places to link the same > object would complicate that, so we need to be careful in designing our > link<>s: Having /machine/node[0]/cpu[0] be a link<> would mean no secon= d > link<> directly on /machine/cpu[0], i.e. the NUMA node acting as a > sub-container of the board; on the other hand having a link<> to the > thread CPUState from some NUMA-specific path outside of the composition > model would still be possible due to the different link<> type but > having cpu[0] be a link to the actual socket object rules out using the > same name for a NUMA-only container object as proposed. >=20 > > or > > device_add dimm,path=3D/machine/node[0]/dimm[5] > > vs > > device_add dimm,node=3D0,slot=3D5 > >=20 > > i.e. being added device could decode all needed information from abov= e > > provided path instead of creating a bunch of custom properties. >=20 > Hm, the advantage of having properties there would be better error > checking in terms of restricting paths. I'd be open to having both. >=20 > I do wonder in both cases if we should use paths relative to /machine t= o > avoid them cluttering the command line? >=20 > Regards, > Andreas >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg