Re: [Xen-devel] [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/18/2014 03:30 PM, Ian Campbell wrote:
> On Wed, 2014-06-18 at 14:58 +0100, George Dunlap wrote:
> > On 06/18/2014 02:49 PM, Ian Campbell wrote:
> > > > > > +        ("backend_domid",    libxl_domid),
> > > > > > +        ("backend_domname",  string),
> > > > > > +        ("u", KeyedUnion(None, libxl_device_usb_type, "type",
> > > > > > +                         [("hostdev", Struct(None, [
> > > > > > +                                ("hostbus",   integer),
> > > > > > +                                ("hostaddr",  integer) ]))
> > > > > No need to express the host topology I think (because you can build that
> > > > > from the bus,addr tuples)?
> > > > I don't really follow.  You mean, we can drop 'host' from the last two
> > > > elements, and just call them "bus" and "addr"?
> > > Gah, I started writing one thing and then reunderstood usb and wrote
> > > half another.
> > >
> > > What I was trying to say is that you don't need hostaddr to describe the
> > > full USB topology path to the device because the (bus,addr) tuple you've
> > > given already does so (because each hub effectively creates a new bus
> > > number, so they all look like toplevel buses in this representation).
> > You seem to be saying that something is redundant, or that there's extra
> > information somewhere; but as there are only two bits of data (bus and
> > addr), and agree that I need both, I'm having a hard time telling what
> > you think is redundant / could be removed..
> I'm actually saying the opposite (or rather asking for confirmation that
> this is the case). i.e. one might expect that *more* information would
> be needed here (i.e. the full bus topology/path to a device via multiple
> hubs etc) but in fact this is not needed because the topology is not
> visible in this numbering scheme (each potential fork in the path
> results in a whole new bus number).
>
> Sorry, I could have been clearer about this.
Ah, I see.  Yes, that's right: <bus,addr> is sufficient to specify a 
single device.
To qemu you can either specify <bus,addr> or <vendorid:productid>.  
Unfortunately both have their advantages and disavantages.  <bus,addr> 
will specify a unique device, but exactly which device that is may 
change across reboots, so you have to check each time that you're still 
passing in your USB stick rather than your webcam.
On the other hang, <vid,pid> will allow you to pass in a specific kind 
of device no matter where it's plugged in... as long as there's only one 
of them.  If you have two webcams / usb devices of the same kind, you're 
out of luck, and you have to fall back to <bus,addr> again.
I considered allowing the user to specify either one, just as you can 
with qemu. (That might mean having libxl do the <vid,pid> -> <bus,addr> 
resolution for PVUSB.)  I'm open to opinions on that one.
 -George


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