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 Thu, 28 Apr 2016, Fabio Fantoni wrote:

> Il 27/04/2016 20:03, Martin Cerveny ha scritto:
> > 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 know, I spoked about what is actually implemented in libxl and below in my 
> old mail there was already details about the other method.
> What I asked are advices on how is good implement the other method (upstream 
> qemu's usbredir tcp channels) in libxl (about the other code in addition to 
> the qmp commands functions itself that I'm writing now in libxl_qmp.c), 2 
> days ago I only did some fast "manual external" tests with Sid and W7 domUs 
> to be sure is it working hotplug (with qmp) before start to implement it in 
> libxl.
> Sorry for my bad english if it is not understandable what I write.
> > 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.
> Have you tried to use an usb3 emulated controller? with the usb3 if I 
> remember good this problem is mitigate.
> If you add usb controller at domU's create with usb=1 (in domU's xl cfg) it 
> add the qemu default than with the old chipset (the only currently used by 
> xen) is usb1 controller, with the q35 (not supported by xen) the default is 
> usb2 controller instead. Can you use usbversion=3 (added in xen 4.4) for add 
> usb3 controller at domU's xl create or add nec-usb-xhci device (hotplug with 
> "manual" qmp command).
Thanks for hint. I tried and I see "nec-usb-xhci" (info qtree) all devices 
pluged (info qtree, info chardev, info usb) and visible in os (lsusb in 
DomU linux) but _USB1_ devices does not work (keyboards/mouses) - tcp 
channel connected and tcpdump verify some network traffic after mouse move 
and/or key press but data probably lost in qemu and DomU does not receive 
mouse and/or keyboard events :-(( (tried windowz 7 too error code 10 on 
USB devices an Qemu HUB).
_USB2_ memory stick works OK in linux (ssh connected to DomU linux).
Qemu load drops to ~1% when idle.

M.C>

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