From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFyqi-0001bL-Ih for qemu-devel@nongnu.org; Tue, 27 Jan 2015 00:38:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFyqU-0000P7-8H for qemu-devel@nongnu.org; Tue, 27 Jan 2015 00:38:04 -0500 Date: Tue, 27 Jan 2015 16:30:10 +1100 From: David Gibson Message-ID: <20150127053010.GE28888@voom.redhat.com> References: <1419337831-16552-1-git-send-email-mdroth@linux.vnet.ibm.com> <1419337831-16552-11-git-send-email-mdroth@linux.vnet.ibm.com> <20150119051528.GT5297@voom.fritz.box> <20150126203558.23721.64052@loki> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: <20150126203558.23721.64052@loki> Subject: Re: [Qemu-devel] [PATCH v4 10/17] spapr_drc: add spapr_drc_populate_dt() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: aik@ozlabs.ru, qemu-devel@nongnu.org, agraf@suse.de, ncmike@ncultra.org, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, bharata.rao@gmail.com, nfont@linux.vnet.ibm.com --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 26, 2015 at 02:35:58PM -0600, Michael Roth wrote: > Quoting David Gibson (2015-01-18 23:15:28) > > On Tue, Dec 23, 2014 at 06:30:24AM -0600, Michael Roth wrote: [snip] > > > +/* generate a human-readable name for a DRC to encode into the DT > > > + * description. this is mainly only used within a guest in place > > > + * of the unique DRC index. > > > + * > > > + * in the case of VIO/PCI devices, it corresponds to a > > > + * "location code" that maps a logical device/function (DRC index) > > > + * to a physical (or virtual in the case of VIO) location in the > > > + * system by chaining together the "location label" for each > > > + * encapsulating component. > > > + * > > > + * since this is more to do with diagnosing physical hardware > > > + * issues than guest compatibility, we choose location codes/DRC > > > + * names that adhere to the documented format, but avoid encoding > > > + * the entire topology information into the label/code, instead > > > + * just using the location codes based on the labels for the > > > + * endpoints (VIO/PCI adaptor connectors), which is basically > > > + * just "C" followed by an integer ID. > >=20 > > Hrm.. would it make sense to include here the qemu "id" value on the > > DRC device? That will make names which are matchable to specific > > elements on the qemu command line, which about as close an equivalent > > to a physical location as I can think of. >=20 > I'm not sure I understand the suggestion. We do make use of the > drc->id values to generate this, though those don't really > correspond to "id"/DeviceState->id properties as specified on > the command-line. There's currently no plans to create the DRCs via > -device since the IDs are dependent on/chosen by the parent devices in > in this case (DRC IDs for PCI slots inherit/encode parent bus/controller > index for example). Did you have something else in mind? I guess I was thinking of building this location code from the DeviceState->id of the bus bridge (or whatever) which created the DRC slot. Basically giving the user a handle on which qemu parameter is related to this hotplug slot. --=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 --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUxyJiAAoJEGw4ysog2bOSdrMP/2TemEPC6mMIOeczDUC8L6qK wfDepPOnnMqam+ZB8vxxBe/bPJUJjL5a8/keBHgoJWP7x6qSq1XwDKdbvqlsRGnz rOrXBMpUWjd+ojnd6KZniBZkOh1OzomOPR20lgOfzUDApPLC/xnx5Gzs0YzcNYSD fePNk9iR1SE9XM7vPCSyaxULQ1X06p1cg1lYYubajVzynMaxjlRLHwGP2TLMzFgt PWgB/b1sQ0jZddHl3fWSNJnmhbcdjQt51HL/p3Ebr9iyo8GAuQXm581nAjTjyC6U lY73cmpzUz27kNDVMb0W0Ypt5Px4ur3jY/7CyNaGi037Ks/77Ihji+aTDQ5KPa/m 66+PrQno62/jwpZf9io2ZlZV4WCoo36NkXaXbQbpc8Kzlo/xKz+5wr1YCQK1UOvP 7Rkjr5USFcx0johGgQeh/PuDCiM9PUM/7KM1eTjXq0Mk28JuWMYe77Ak47qfeS4J Rndo0dSC0YAEIhEj3S0AxaFVq8ACBC0JXwXT0ZO64+dtDWy+U3L+c3Vk+9fPrXL2 f3zNj7z4nK7oPx1mZ0XhnJYfvS8aE0NcfKghYnEvqqH0+zaAY9U+0uh49EEkwRQV O+ow83YoPKfmobDaB8jp0UkshjpU/Q/DFbrJtI2jholrK7VAaqEV4vuEhleJl3qy orittwGibKJwbWEGBmG8 =v3pn -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk--