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

[Jan Kiszka]

Markus Armbruster wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> Markus Armbruster wrote:
>>> Paul Brook <address@hidden> writes:
>>>
>>>> Alex Williamson <address@hidden> writes:
>>>>
>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>> parent bus and device"?  They make the result ver much *not* a "dev
>>>>>> path" in the qdev sense...
>>>>> In order to try to get a unique string.  Without looking into device
>>>>> properties, two e1000s would both be:
>>>>>
>>>>> /main-system-bus/pci.0/e1000
>>>>> /main-system-bus/pci.0/e1000
>>>>>
>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>> to instance ids again.  The goal here is that anything that makes use of
>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>> You already got the information you need, you just put it in the wrong 
>>>> place. 
>>>> The canonical ID for the device could be its bus address. In practice we'd 
>>>> probably want to allow the user to specify it by name, provided these are 
>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci 
>>>> would 
>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so 
>>>> we 
>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>
>>>> 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).
>>> When that's inconvenient or impossible, we can still punt to user: make
>>> device ID mandatory.
>> No option due to auto-created devices. And auto-generating IDs would
>> just create usability issues.
> 
> Auto-generated IDs would become part of the ABI.  Really so bad that
> it's "no option"?  Mind, device ID becomes mandatory *only* for devices
> that don't have a useful bus address.  We could even waive the ID
> requirement for the first device of a kind, i.e. require ID if and only
> if it's needed to disambiguate.

IDs are there to find devices the user (or a higher level tool) passed
to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
a well-organized hierarchy. That allows to explore and address a qtree
element at the same time.

> 
>>> We obviously need a way to unambigously name a device.  It's okay to
>>> have multiple names for the same device.
>>>
>>> If the device has a device ID, that's an unambigous name.
>>>
>>> qdev paths may be ambigous when path components are resolved to driver
>>> names instead of IDs.
>>>
>>> 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.
> 
> I'm not arguing against the use of driver names at all.
> 
>>> 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.
> 
> It's not either/or.  Addressing by ID continues to work.  Addressing by
> bus/driver-name continues to work.  We merely add addressing by
> bus/@bus-address.

The format I will propose is "global-ID|/absolute/path", no more
/path/global-ID as this comes with the risk of ambiguity (ID may shadow
bus-local name of a device).

> 
>>> 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.
> 
> I object to <driver>@<bus-address>, because the <driver> part carries no
> information.

I does for a human being as bus addresses tend to be unreadable and can
easily be confused, hence the additional, sometimes redundant driver name.

> 
> Not the case for <driver>.<instance-no>.  We still need a suitable
> definition of <instance-no>.  Possible definitions:
> 
> * n-th creation of a <driver> device.  Drawbacks: depends on creation
>   order.  Relatively hard to maintain across migration.
> 
> * n-th instance of a <driver> device.  Drawback: changes on unplug.
>   Good enough for interactive use, but it doesn't provide a stable
>   device name.

Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.

> 
> When counting <driver> devices either way, we can count per bus or
> globally.  I prefer per bus.

Yes, counting should be both per-driver and per-bus ("the <n>th device
managed by <driver> on this bus").

> 
> None of the above instance numbers are nearly as neat as bus addresses.

Right, wherever they are available.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux