Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()

[Alex Williamson]

On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote: 
> >> And instead of introducing another hierarchy level with the bus address,
> >> I would also prefer to add this as prefix or suffix to the device name,
> >> e.g. <driver>.<busaddr>.
> > 
> > That's what I had started with.  The first post in this thread has
> > "pci.0,addr=09.0" as a single hierarchy level.  The "addr=" may be
> > unnecessary there, but I also prefer something along those lines.  For
> > PCI it'd make sense to have <name>:<addr>, which comes out to
> > "pci.0:09.0".  (Maybe rather than flagging properties as being relevant
> > to the path and printing them generically, we should extract specific
> > properties based on the bus type.)
> 
> Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> there are slots on that bus.

Ok, I can get it down to something like:

/i440FX-pcihost/pci.0/virtio-blk-pci,09.0

The addr on the device is initially a little non-intuitive to me since
it's a property of the bus, but I guess it make sense if we think of
that level as slot, which includes an address and driver.

> >>>> For busses that don't have a consistent addressing scheme then some sort 
> >>>> of 
> >>>> instance ID is unavoidable. I guess it may be possible to invent 
> >>>> something 
> >>>> based on other device properties (e.g. address of the first IO 
> >>>> port/memory 
> >>>> region).
> >>> Instance IDs aren't always bad, we just run into trouble with hotplug
> >>> and maybe creating unique ramblock names.  But, such busses typically
> >>> don't support hotplug and don't have multiple instances of the same
> >>> device on the bus, so I don't expect us to hit many issues there as long
> >>> as we can get a stable address path.  Thanks,
> >>>
> >> If stable instance numbers are required, we could simply keep them in
> >> DeviceState and search for the smallest free one on additions. Actually,
> >> I'm more in favor of this direction than including the bus address. That
> >> way we could keep a canonical format across all buses and do not have to
> >> provide possibly complex ID generation rules for each of them.
> > 
> > I started down that path, but it still breaks for hotplug.  If we start
> > a VM with two e1000 NICs, then remove the first, we can no longer
> > migrate because the target can't represent having a single e1000 with a
> > non-zero instance ID.
> 
> That's indeed a good point.
> 
> Still, I'm worried about having to define numbering schemes for all the
> buses qemu supports. Maybe we can run a mixture: address-based for
> hotplug-capably buses (they tend to be cooperative in this regard) and
> simple instance numbers for the rest, likely the majority.

Yep, I share that concern, which is I say instance numbers aren't always
bad.  If we have devices that we don't care about doing hotplug on, we
can live with instance numbers.  Thanks,

Alex