Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Juergen Gross <jgross@xxxxxxxx>]

On 06/16/2015 01:11 PM, George Dunlap wrote:
> On Tue, Jun 16, 2015 at 11:51 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> > > The "busid" interface that Chunyan is describing requires the caller
> > > to find out that long name -- 2-3.1.2 -- rather than the traditional
> > > short name (002:010).  Just accepting "2-3" is not sufficient.
> >
> > qemu with my patch will find the device only if the long name is used.
> > So the "port" in qemu would be "3.1.2" in your example above.
> Ah, right -- sorry, looking at the patch I saw that "port" was
> converted using strtoul, but now I see that was "bus", and that "port"
> is a string.  That's what I was missing.
>
> > BTW: be careful with the syntax: x:y is used by qemu to specify a device
> > by vendorId:productId, you should write "002.010" to use the short name
> > above.
> Yes, thanks for the reminder.  I knew there was some way to
> distinguish bus.addr and vendor:device, but I'd forgotten the exact
> semantics.
>
> So as Juergen says, the typical way to write these would be:
> - bus-port; e.g., 2-3.1.2  is bus=2, port=3.1.2.  Stable in topology,
> not in device
Nah, not stable in topology. At least on my laptop I've seen a memory
stick plugged in at the same position as "3-3" or as "1-3".

I'm pretty sure this is just a matter of timing during boot: the busses
are all (or at least some of them) queried at the same time and the
first answering gets number 1, the next 2, and so on. And timing seems
to be different enough to result in unstable bus numbers.


Juergen

> - bus.addr: e.g., 2.10 is bus=2, address=10.  Unique every time a
> device is plugged in (so no risk of aliasing, but not stable across
> reboots)
> - vendorid:deviceid: e.g., 1050:0111 is vendorid=1050, deviceid=0111.
> Stable on device class (so same no matter when or where you plug it
> in, but can't tell two identical devices apart).
>
>   -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel