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

[Markus Armbruster]

Alex Williamson <address@hidden> writes:

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

/ is the main system bus.  System bus defines no bus address at the
moment.  Therefore, you have to use the driver name i440FX-pcihost.

/i440FX-pcihost/pci.0 is the PCI bus.  PCI bus defines a bus address:
dev.fn.  Therefore, you can either use the bus address @05.0, or the
driver name e1000.

We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".

> 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.
>
> Another example; if we have two drivers that create a vmstate with name
> "foo", plug one driver into slot 03.0 on the migration source, the other
> into slot 03.0 on the migration destination, what happens?  It seems
> likely that the destination will try to load the vmstate from a
> different driver and fail in wonderful and bizarre ways.  If we use (A),
> each path automatically has it's own namespace.
>
> ISA is also a good example even though it doesn't do hotplug.  Given
> this set:
>
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
>
> versus this set:
>
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x3f8
> /pci.0.01.0/isa.0/0x378
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x300
>
> Which one has devices that are easier to uniquely identify?
>  
>> > > 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.

Identifying a device on a given VM is all a qdev path does.

If you want to check two VMs have the same device in the same slot, then
you need to compare *devices*, not their names.  You propose to encode
*one* property of the device in the name, namely its driver.  This is
far from sufficient.  If you tell me you need it anyway for migration,
I'll have to take that at face value (I'm not an expert there).  But
please do not call it "qdev path", because it ain't.

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

Migration needs to recreate the same qdev tree on the destination.
Driver name is just *one* property of a device.  Migration needs to
transfer *all* properties.  Why encode driver name in the path, but not
the rest?  Why can't you put the driver name wherever you put the rest?

>> > > An easy way to get that is to reserve part of the name space for bus
>> > > addresses.  If the path component starts with a letter, it's an ID or
>> > > driver name.  If it starts with say '@', it's a bus address in
>> > > bus-specific syntax.  The bus provides a method to look it up.
>> > 
>> > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> > set for buses that implement some to-be-defined device addressing
>> > service, the latter is the default on buses where that service is not
>> > available.
>> 
>> If we have bus-address then I see no good reason to also add instance-no.
>> For busses that no natural address, we can define the address to be an 
>> instance number.
>
> I agree, it should be a bug for any device with a bus address to have an
> instance number other than zero.  Anything without a bus number can make
> use of instance numbers, and hopefully will never be hotplugged.
>
>> > > That way, we gain a useful feature, and avoid having an savevm-specific
>> > > "device path" that isn't recognized anywhere else.
>> > 
>> > Agreed, we should find one solution for all use cases.
>> 
>> I wasn't aware that there was any suggestion of a separate savevm-specific 
>> path.  The whole point of a device path is to uniquely identify a device 
>> within a machine. There may be many different paths that identify the same 
>> device.  When given a device and asked to generate  path, the result should 
>> be 
>> the canonical address.  IMO this should be the least volatile, and avoid 
>> redundant information.

Agree.

[...]