[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |