[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/16/2015 12:30 PM, George Dunlap wrote:
On Mon, Jun 15, 2015 at 7:26 PM, Juergen Gross <jgross@xxxxxxxx> wrote:
On 06/15/2015 04:34 PM, George Dunlap wrote:
On Mon, Jun 15, 2015 at 3:25 PM, JÃrgen Groà <jgross@xxxxxxxx> wrote:
On 06/15/2015 04:17 PM, George Dunlap wrote:
On Wed, Jun 10, 2015 at 4:20 AM, Chunyan Liu <cyliu@xxxxxxxx> wrote:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 23f27d4..4561e1b 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -541,6 +541,29 @@ libxl_device_pci = Struct("device_pci", [
("seize", bool),
])
+libxl_usb_protocol = Enumeration("usb_protocol", [
+ (0, "AUTO"),
+ (1, "PV"),
+ (2, "QEMU"),
+ ])
+
+libxl_device_usbctrl = Struct("device_usbctrl", [
+ ("protocol", libxl_usb_protocol),
+ ("devid", libxl_devid),
+ ("version", integer),
+ ("ports", integer),
+ ("backend_domid", libxl_domid),
+ ("backend_domname", string),
+ ])
+
+libxl_device_usb = Struct("device_usb", [
+ ("ctrl", libxl_devid),
+ ("port", integer),
+ ("busid", string),
+ ("hostbus", integer),
+ ("hostaddr", integer),
+ ])
Ian / Ian / Wei / Jim:
Question about the design of the interface here.
The way that most systems in Linux specify particular USB devices is
with the bus:addr format. It's the output you get when you run tools
like lsusb, for example, and it's the interface that qemu (and thus
KVM) uses when talking about host devices to assign. bus:addr might
look like "002:006".
But the bus:addr is a "public api" for Linux; internally, it has a
more structured format, which contains more about the USB topology.
Chunyan is calling this "busid". An example is something like this:
"2-3.1.1:1.0".
Internally, pvusb needs "busid" in order to find the right sysfs
files. qemu, on the other hand, does not take busid; so the
devicemodel / HVM implementation of USB would need bus:addr
internally.
A patch for qemu to support the busid is trivial, as the structures
already contain the necessary elements:
--- a/hw/usb/host-legacy.c
+++ b/hw/usb/host-legacy.c
@@ -53,11 +53,6 @@ static int parse_filter(const char *spec, struct
USBAutoFilter *f)
const char *p = spec;
int i;
- f->bus_num = 0;
- f->addr = 0;
- f->vendor_id = 0;
- f->product_id = 0;
-
for (i = BUS; i < DONE; i++) {
p = strpbrk(p, ":.");
if (!p) {
@@ -100,32 +95,47 @@ USBDevice *usb_host_device_open(USBBus *bus, const
char
*devname)
dev = usb_create(bus, "usb-host");
+ memset(&filter, 0, sizeof(filter));
+
if (strstr(devname, "auto:")) {
if (parse_filter(devname, &filter) < 0) {
goto fail;
}
- } else {
- p = strchr(devname, '.');
- if (p) {
- filter.bus_num = strtoul(devname, NULL, 0);
- filter.addr = strtoul(p + 1, NULL, 0);
- filter.vendor_id = 0;
- filter.product_id = 0;
- } else {
- p = strchr(devname, ':');
- if (p) {
- filter.bus_num = 0;
- filter.addr = 0;
- filter.vendor_id = strtoul(devname, NULL, 16);
- filter.product_id = strtoul(p + 1, NULL, 16);
- } else {
- goto fail;
- }
- }
+ goto out;
}
+ /* Check for <bus>-<port> specification. */
+ p = strchr(devname, '-');
+ if (p && p != devname) {
+ filter.bus_num = strtoul(devname, NULL, 0);
+ filter.port = p + 1;
+ goto out;
+ }
On my system bus:addr for my mouse is 002:005, while the "busid" (the
corresponding directory in sysfs) is 2-3.3.
This code doesn't appear to me to parse the above properly; or did I
miss something?
Filling filter.bus_num and filter.port is enough. This was the only part
missing in qemu, finding the device via libusb using bus_num and port is
already existing. At least it is working for me. :-)
Well, one of us is completely wrong.
Let's follow the example above:
$ ls /sys/bus/usb/devices/2-3*
/sys/bus/usb/devices/2-3@
/sys/bus/usb/devices/2-3.1@
/sys/bus/usb/devices/2-3:1.0@
/sys/bus/usb/devices/2-3.1.1@
/sys/bus/usb/devices/2-3.1:1.0@
/sys/bus/usb/devices/2-3.1.1:1.0@
/sys/bus/usb/devices/2-3.1.2@
/sys/bus/usb/devices/2-3.1.2:1.0@
/sys/bus/usb/devices/2-3.1.2:1.1@
/sys/bus/usb/devices/2-3.2@
/sys/bus/usb/devices/2-3.2:1.0@
/sys/bus/usb/devices/2-3.3@
/sys/bus/usb/devices/2-3.3:1.0@
$ for i in /sys/bus/usb/devices/2-3*/; do grep . $i/{bus,dev}num ; done
/sys/bus/usb/devices/2-3//busnum:2
/sys/bus/usb/devices/2-3//devnum:2
/sys/bus/usb/devices/2-3.1//busnum:2
/sys/bus/usb/devices/2-3.1//devnum:3
/sys/bus/usb/devices/2-3.1.1//busnum:2
/sys/bus/usb/devices/2-3.1.1//devnum:6
/sys/bus/usb/devices/2-3.1.2//busnum:2
/sys/bus/usb/devices/2-3.1.2//devnum:10
/sys/bus/usb/devices/2-3.2//busnum:2
/sys/bus/usb/devices/2-3.2//devnum:4
/sys/bus/usb/devices/2-3.3//busnum:2
/sys/bus/usb/devices/2-3.3//devnum:5
$ lsusb | grep "Bus 002"
Bus 002 Device 005: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 004: ID f617:0905
Bus 002 Device 010: ID 1050:0111 Yubico.com
Bus 002 Device 006: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 002 Device 003: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
In other words, there are 6 distinct devices that correspond to "bus 2
port 3". I don't know what it was you were passing through, but
giving qemu (or libusb) only "2-3" is absolutely not enough for it to
distinquish between my mouse (002:005, at 2-3.3) and my yubikey
(002:010 at 2-3.1.2). That's why the bus:addr convention was invented
in the first place, I presume -- to abstract away the topology of the
USB hubs for the user.
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.
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.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
