[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

 


Rackspace

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