[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] USB passthrough with Xen on ARM
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. > Juergen, do you have other idea why it would timeout? qemu not running or without qusb support is the most probable one. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |