[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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

 


Rackspace

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