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

Alex Williamson
2010-06-15T22:33:25Z

On Tue, 2010-06-15 at 22:55 +0100, Paul Brook wrote:
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > > immediate parent bus and device" to the path component. For PCI,
> > > > > these are dev.fn. Likewise for any other bus where devices have
> > > > > unambigous bus address. The driver name carries no information!
> > > >
> > > > From user POV, driver names are very handly to address a device
> > > > intuitively - except for the case you have tones of devices on the same
> > > > bus that are handled by the same driver. For that case we need to
> > > > augment the device name with a useful per-bus ID, derived from the bus
> > > > address where available, otherwise based on instance numbers.
> > >
> > > This is where I think you're missing a trick. We don't need to augment
> > > the name, we just need to allow the bus id to be used instead.
> >
> > For the case of a hot remove, I agree. If the user specifies "pci_del
> > pci.0/03.0", that's completely sufficient because we don't care what's
> > in that slot, just remove it. However, I still see some use cases for
> > device names in the path. Take for example:
> >
> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >
> > vs
> >
> > (B): /pci.0/05.0
>
> > (removing both the root bridge driver name and the device driver name)
>
> This is wrong. You still need an entry for the host pci bridge.

The host pci bridge has no identifying properties, so all we'd be
printing is the pci bridge driver name, which we claim adds no value.
Or are we saying that some driver names are useful while others aren't?

> > If we attach a pci option rom to the device, create some ram to store
> > the option rom and name the ram block $(PATH)/rom, with (A) we know more
> > about the hierarchy to get to the actual devfn device, and we know the
> > type of device that's in the slot. With (B), there's no robustness. If
> > we migrated using (B), we could be stuffing a pc e1000 option rom into a
> > ppc lsi895, just because it happened to live that the same place and
> > have a ram block named rom. Including driver names increases the
> > uniqueness of the path.
>
> No it doesn't. It adds redundant information and a false sense of security.
> Driver name is not sufficient to determine whether you've actually got a
> compatible device. The type of the device doesn't reliably tell you anything
> about how many ram blocks that device has, or how big they are.

Driver name is sufficient to tell me that driver "foo" created this
device on both the source and destination and hand off responsibility to
driver "foo" to make the determination about whether it's compatible. I
think it's reasonably safe to say we're not going to have two completely
different drivers with name "foo"s within an instance of qemu and we're
not going to turn over the name to a different driver and expect
anything sane to happen wrt to migration. I disagree that this is a
false sense of security, it gives me warm fuzzies. Please convince me
otherwise.

> > > > > For other buses, we need to make something up.
> > > > >
> > > > > Note that addressing by bus address rather than name is generally
> > > > > useful, not just in the context of savevm. For instance, I'd
> > > > > appreciate being able to say something like "device_del pci.0/04.0".
> > > >
> > > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > > > the bus first before you can identify which device you want to remove.
> > >
> > > We can allow both.
> > > A bus address is sufficient to uniquely identify a device.
> >
> > A bus address (assuming it exists) is sufficient to uniquely identify a
> > device, on a given VM. A bus address only identifies a location when
> > comparing two separate VMs.
>
> I can't make any sense of this statement.

Makes sense to me ;) A bus address is unique only within the context of
the VM. Within that VM I can figure out that the device at that bus
address uses driver foo, so foo seems redundant in the device path. Now
I try to apply that bus address to another VM, the migration target, and
all I have is a location. I have to make a leap of faith that the
device at that location is the same as the device at the same location
on the migration source. Where are those warm fuzzies?

> > > I see no reason to
> > > require the driver name, or to include it in the canonical device
> > > address.
> >
> > Migration. Including the driver name extends our ability to uniquely
> > identify a device across separate VMs. It's then up to the vmstate code
> > to figure out whether the device are compatible for migrate state.
>
> I find this argument contradictory. The migration code already needs to check
> whether a device is compatible before it allows migration. The driver name is
> not sufficient to ensure compatibility, so I see no benefit in including it in
> the device address.

See my comment above, I'm not seeing a sufficient argument about why
driver name matching is a false sense of security. If on an incoming
migration I'm able to match the source provided e1000.03.0/vmstate
against the target registered e1000.03.0/vmstate and hand off to the
e1000 driver to check version ids, you bet I'm feeling a lot more secure
than if I'm handing off to whatever happened to register 03.0/vmstate on
the target.

> If we include the device name, why aren't we also
> including all other properties that would make the devices incompatible?

Well, in some ways that'd be really nice, then we could rebuild the
device on the fly in the target. But, I'm attempting to work within the
existing migration code, because I'd really like something working
better than it does today very soon. Therefore, we do want to reduce
the path to only those elements that are stable and add value. I argue
the driver name is both stable and adds value. Thanks,

Alex