Re: [Xen-devel] Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Apr 27, 2016 at 7:03 PM, Martin Cerveny <martin@xxxxxxxxx> wrote:
>
>
> On Wed, 27 Apr 2016, Fabio Fantoni wrote:
>
>> Il 27/04/2016 13:26, George Dunlap ha scritto:
>>>
>>> On 27/04/16 12:02, Fabio Fantoni wrote:
>>>>
>>>> Hi, I took a look at the new pvusb hotplug code in libxl to try to add
>>>> also hotplug (with qmp) usbredir tcp channels.
>>>> Adding usbredir tcp channels at domU start requires for example adding
>>>> qemu parameters like these: "-chardev
>>>> socket,id=charredir4,host=192.168.1.35,port=40000 -device
>>>> usb-redir,chardev=charredir4,id=redir4".
>>>> It is possible to hotplug it with qmp using "chardev-add" and
>>>> "device_add" commands.
>>>> Looking at old George Dunlap's patches I tested years ago
>>>>
>>>> (http://xenbits.xen.org/gitweb/?p=people/gdunlap/xen.git;a=commitdiff;h=f7a77843e3fcf070c72115be8ed349a3bfe34e60)
>>>> I can understand what they do and I can add similar qmp functions for
>>>> usbredir tcp too.
>>>> But now I see that bigger and different usb hotplug code was added, I
>>>> looked at these patches:
>>>>
>>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=bf7628f087b212052a0e9f024044b2790c33f820
>>>>
>>>>
>>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=043910384cb9ea2c781a7dceac238e110a559c10
>>>>
>>>> and the full current code in xen's staging branch but I didn't find qmp
>>>> commands for the qemu usb passthrough, I suppose it is missing or
>>>> incomplete (though strange), am I wrong?
>>>> If that is correct, pvusb drivers are needed for both host and domU to
>>>> have usb passthrough working but in new windows pv drivers, the pvusb
>>>> one is missing, so without the "qemu emulated" usb passthrough it
>>>> doesn't work at all in similar cases, right?
>>>
>>> That's right -- the PVUSB code *only* does PVUSB passthrough.  The
>>> interface was designed, however, to be able to add emulated USB on top.
>>>
>>>> How do you think I should proceed to implement hotplug usbredir tcp
>>>> channels in libxl?
>>>
>>> So I'm not familiar with usbredir tcp channels.  I'm guessing that it
>>> allows you to transmit the USB commands "over the wire", so that you
>>> could connect (say) a keyboard or printer on your local computer to the
>>> qemu process running in a remote dom0, and have the USB device presented
>>> as an emulated device to the guest?
>>
>>
>> Yes.
>> In qemu upstream there are 2 methods of usbredir use, one is "dynamic"
>> using spice. I made a quick and easy implementation in libxl some time ago
>> at domU's create:
>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=f5414ee57a17500e650ea11766474b11da940da2
>> this also requires an emulated usb<1|2|3> controller, which I added with
>> this:
>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=bba6747189fb9c4cb51f3c99977d224615106c59
>> It works fine with both windows and linux domUs and I already use it in
>> production but it works ONLY using spice.
>
>
>
>
> Not right. The usbredir is _separated_ protocol from spice
> (http://www.spice-space.org/page/UsbRedir).

I took Fabio to mean, "I have remote USB already using spice protocol;
I'd like to be able to have remote USB *without* spice, and usbredir
is the way to do that".

> I am using this protocol successfully with raspberry-pi "remote usb server":
> - local usb <libusb.h> enumerator and filter
> - remote qmp sender to qemu (<json/json.h>) (chardev-add/device_add) to
>   program "tcp listen" port on qemu
>   eg. "remotely" do full automation/filtering (hotplug) - and usbredir
> server (<usbredirhost.h>) connected to prepared port qemu
>
> (this is part of my VDI solution
> https://gridforums.nvidia.com/default/topic/752/grid-vgpu-benchmarks/vdi-click-to-photon-with-raspberry-pi/)
>
> I will be very pleased if paravirtualized-usb channel will be created
> with usb redir protocol in mind. There is problems in qemu "emulation" speed
> - when usb is remotely attached qemu takes about 20% cpu (probably problem
> of active "pooling" usb devices DomU/Dom0) without any traffic on tcp
> channel.

This certainly sounds like a reasonable feature to have.  It would
take someone looking to see if the usbredir stuff could be hooked up
to the qusb code, and then someone thinking about what an interface to
libxl would look like.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel