[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] USB passthrough with Xen on ARM
On 13/09/17 12:33, Roger Quadros wrote: > Hi, > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 12/09/17 18:28, Juergen Gross wrote: >> On 12/09/17 17:08, Julien Grall wrote: >>> Hello, >>> >>> On 12/09/17 12:22, Roger Quadros wrote: >>>> >>>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >>>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >>>> >>>> On 12/09/17 13:57, Julien Grall wrote: >>>>> Hi, >>>>> >>>>> On 12/09/17 11:00, Juergen Gross wrote: >>>>>> On 12/09/17 10:13, Roger Quadros wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm running Xen v4.9 on DRA7 (OMAP5/ArmV7) with Linux kernel v3.14 >>>>>>> (yikes!!) on dom0 and domU. >>>>>>> I'm struggling to get USB passthrough working using pvUSB. >>>>>>> >>>>>>> My domU config file contains >>>>>>> usb = 1 >>>>>>> usbctrl = ['type=qusb,version=2,ports=4', >>>>>>> 'type=qusb,version=1, ports=4', ] >>>>>>> >>>>>>> I can see the vusb-0 and vusb-1 platform devices in /sys/devices >>>>>>> >>>>>>> And the following message on domU kernel log >>>>>>> [ 1.849572] xenbus_probe_frontend: Device with no driver: >>>>>>> device/vusb/0 >>>>>>> [ 1.849627] xenbus_probe_frontend: Device with no driver: >>>>>>> device/vusb/1 >>>>>>> >>>>>>> This means that there is no device driver for the vusb host >>>>>>> controllers. >>>>>>> >>>>>>> What is the way forward? Do I need to apply some patches to the >>>>>>> domU kernel to >>>>>>> add support for the USB frontend HCD drivers? >>>>>> >>>>>> This is one mandatory step, yes. You'll need: >>>>>> >>>>>> https://lkml.org/lkml/2015/6/23/34 >>>>>> https://lkml.org/lkml/2015/6/23/36 >>>>>> >>>> >>>> OK, after applying the above 2 patches to v4.12 kernel for domU I'm >>>> able to see the xen HCD driver >>>> enumerate, but it times out most likely due to the missing pvusb backend. >>>> >>>> [ 0.510149] vusb vusb-0: Xen USB2.0 Virtual Host Controller >>>> [ 0.510192] vusb vusb-0: new USB bus registered, assigned bus number 1 >>>> [ 0.510811] hub 1-0:1.0: USB hub found >>>> [ 0.510865] hub 1-0:1.0: 4 ports detected >>>> [ 0.812721] vusb vusb-1: Xen USB1.1 Virtual Host Controller >>>> [ 0.812760] vusb vusb-1: new USB bus registered, assigned bus number 2 >>>> [ 0.813356] hub 2-0:1.0: USB hub found >>>> [ 0.813410] hub 2-0:1.0: 4 ports detected >>>> >>>> ... >>>> >>>> [ 5.888997] xenbus_probe_frontend: Waiting for devices to >>>> initialise: 25s...20s...15s...10s...5s...0s... >>>> [ 35.919000] >>>> 235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... >>>> >>>> [ 270.879130] >>>> [ 270.884161] xenbus_probe_frontend: Timeout connecting to device: >>>> device/vusb/0 (local state 1, remote state 1) >>>> [ 270.887059] xenbus_probe_frontend: Timeout connecting to device: >>>> device/vusb/1 (local state 1, remote state 1) >>>> >>>>>> The question is whether this will be enough for you to make it work: >>>>>> the >>>>>> pvusb backend is qemu based. I'm not sure this will just work on ARM. >>>>> >>>>> Backends in QEMU should just work with ARM. Although, I haven't tried >>>>> the PVUSB one. >>>>> >>>> >>>> Newbie question now. How do I start the QEMU pvusb backend on dom0? >>> >>> If I am not mistaken, the backend should be started by >>> "/etc/init.d/xencommons start" which also start xenstore and all the >>> userspace components for Xen. >> >> No, it should be started by libxl as a per-domain device model. >> >>> So you should have a QEMU running in Dom0. Can you check if it is the case? >> >> You should see whether the device model is started by doing >> >> xl -vvv create ... >> >> When the domain has been started you can call >> >> xenstore-ls >> >> to see whether there are any device model related xenstore entries. >> There should be some like: >> >> /local/domain/0/device-model/<domid>/backends/<backend> >> >> <backend> being "qusb" is the one you will need. >> >>> Also, I would check that QEMU has been built with the PV USB backend. It >>> depends on libusb. I am not entirely sure if the build system will >>> require it and will therefore fault if it is not installed. >> >> It won't. It will disable the backend without libusb being available. > > This was exactly the problem. I had to rebuild xen tools with libusb-dev > installed. > The timeout issue went away after that. > > However, looks like v4.12 kernel in domU with v3.14 kernel in dom0 doesn't > work together > as things broke when a new USB device was attached to the virtual root hub. > Backtrace in domU > is pasted at the end. I guess the patches might need to be adapted to kernel 4.12. :-) > I resolved this issue by backporting the xen-hcd kernel patches to v3.14 and > running the v3.14 > kernel in domU. Although I see this message in dom0. but it doesn't seem to > cause any problems > with the USB device in domU in my limited tests. > > [ 3495.812130] xhci-hcd xhci-hcd.1.auto: Setup ERROR: setup context command > for slot 1. > [ 3495.932104] xhci-hcd xhci-hcd.1.auto: Setup ERROR: setup context command > for slot 1. > > One more question. Did I understand correctly that it is not possible to use > full USB host emulation > (usbctrl type=devicemodel) with a PV guest like Linux? If this understanding > is wrong then some pointers > on how to do that would be geat. I don't think this is supported by Xen on ARM. On x86 this is working with HVM or PV guests. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |