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

[Alex Williamson <alex.williamson@redhat.com>]

On Mon, 2010-06-14 at 22:43 +0100, Paul Brook wrote:
> > On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > > Alex Williamson wrote:
> > 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.
> 
> That indicates you're thinking about things the wrong way.
> The point of this path is to uniquely identify an entity.
> 
> /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost 
> device. To identify a device attached to that bus all you need to know is the 
> devfn of the device.

Hmm, I think that identifies where the device is, not what the device
is.  It's more helpful to say "the e1000 in slot 7" than it is to say
"the device in slot 7".

> For an end-user it may be helpful to allow devices to be identified by the 
> device type (assuming only one device of a particular type on that bus), or 
> specify the device type as a crude error checking mechanism. However we're 
> talking about canonical addresses. These need not include the device type. 
> Verifying that the device is actually what you expect is a separate problem, 
> and the device type is not sufficient for that.
> 
> i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.

We seem to keep introducing new problems, and I'm not sure this one
exists.  If I drop the device name/type and use only the devfn, then
what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
into the /rtl8139,09.0/rom (/,09.0/rom) on a migration?  (or we match it
to /09.0/savevm when trying to migrate state)  We can argue that "e1000"
isn't a sufficient identifier, but I can't think of a case where it'd
fail.

> > > > 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.
> 
> That's a feature. If you start with two NICs and remove the first, the chances 
> are that the second will be in a different place to the nice created in a 
> single-nic config. Allowing migration between these two will cause a PCI 
> device to suddenly change location. This is not physically or logically 
> possible, and everyone looses.

If the BAR addresses don't follow the VM when it's migrated, that's
another bug that needs to be fixed, but we can't get there until we at
least have some infrastructure in place to make that bug possible.

> Hot-removing a nic and then hotplugging a new nic in the same location may 
> result in something that is reasonable to migrate.

It might... it might not.  I'd rather make it work than try to document
the restrictions.

Alex