[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

 


Rackspace

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