Re: [Qemu-devel] [PATCH v4 10/17] spapr_drc: add spapr_drc_populate_dt()

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

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.
> > 
> > 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.
> 
> 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.

-- 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]