[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.