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

[Martin Cerveny <martin@xxxxxxxxx>]

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 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.

Thanks, Martin Cerveny


> I want to add the other method to make passthrough of client usb devices 
> possible without spice too.
> Adding it at domU's create is quick and easy, I could do something like the 
> first patch posted above which use the usb controller provided by the other 
> patch but unfortunately the addition of usbredir tcp channels is not 
> "dynamic" as with spice, but it needs a specific target (ip and port) running 
> usbredirserver, so usbredir tcp will be nearly always used "hotplug" with the 
> domU running.
> Hotplug can be done with qmp using "chardev-add" and "device_add" commands, 
> and similar commands for remove. Keeping track of current usbredir channels 
> can be done with the xenstore, like pvusb does, I suppose.
> I think that making it hotplug should be done with care and if possible 
> without making it incompatible with others usb passthrough methods.
> So I wonder how it should be done in practice.
>
> > If so, then:
> > 1. It may be possible using Juergen's qusb work to act as a usbredir tcp
> > channel <-> pvusb bridge
> > 2. But having the devices presented to Windows guests without pvusbfront
> > drivers would depend on having emulated USB working first.
> Here I don't understand exactly what you mean, usbredir tcp channels are 
> created by upstream qemu and use an emulated usb controller that should be 
> already present or added before. I don't know how to use a pvusb instead and 
> I suppose it will require specific changes to be done in qemu.
> > I'm working up a draft implementation of the emulated USB just so I can
> > make sure the current interface is suitable to extend it before it
> > becomes public (and thus needs to be supported).
> The current pvusb code added recently is more bigger/complex and I have 
> difficulties to understand it by following all the relevant code paths. I'm 
> trying to understand if a usbredir tcp channels hotplug implementation can be 
> based on it. I suppose it will be possible after adding the full emulated usb 
> passthrough case.
> Any advice is appreciated.
>
> > I'm not sure how the usbredir tcp channel interacts with emulated
> > controllers; that's what will determine what the libxl interface will
> > look like.
> >
> > Peace,
> >   -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel