* Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels @ 2016-04-27 11:02 Fabio Fantoni 2016-04-27 11:26 ` George Dunlap 0 siblings, 1 reply; 8+ messages in thread From: Fabio Fantoni @ 2016-04-27 11:02 UTC (permalink / raw) To: xen-devel Cc: jgross, Wei Liu, George.Dunlap, cyliu, Anthony.Perard, caobosimon 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? How do you think I should proceed to implement hotplug usbredir tcp channels in libxl? Thanks for any reply and my bad English. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-27 11:02 Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels Fabio Fantoni @ 2016-04-27 11:26 ` George Dunlap 2016-04-27 15:35 ` Fabio Fantoni 0 siblings, 1 reply; 8+ messages in thread From: George Dunlap @ 2016-04-27 11:26 UTC (permalink / raw) To: Fabio Fantoni, xen-devel Cc: jgross, Wei Liu, George.Dunlap, cyliu, Anthony.Perard, caobosimon 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? 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. 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). 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-27 11:26 ` George Dunlap @ 2016-04-27 15:35 ` Fabio Fantoni 2016-04-27 18:03 ` Martin Cerveny 0 siblings, 1 reply; 8+ messages in thread From: Fabio Fantoni @ 2016-04-27 15:35 UTC (permalink / raw) To: George Dunlap, xen-devel Cc: jgross, Wei Liu, George.Dunlap, cyliu, Anthony.Perard, caobosimon 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. 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-27 15:35 ` Fabio Fantoni @ 2016-04-27 18:03 ` Martin Cerveny 2016-04-28 8:35 ` George Dunlap 2016-04-28 14:20 ` Fabio Fantoni 0 siblings, 2 replies; 8+ messages in thread From: Martin Cerveny @ 2016-04-27 18:03 UTC (permalink / raw) To: Fabio Fantoni Cc: jgross, xen-devel, Wei Liu, George.Dunlap, George Dunlap, cyliu, Anthony.Perard, caobosimon 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@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-27 18:03 ` Martin Cerveny @ 2016-04-28 8:35 ` George Dunlap 2016-04-28 14:20 ` Fabio Fantoni 1 sibling, 0 replies; 8+ messages in thread From: George Dunlap @ 2016-04-28 8:35 UTC (permalink / raw) To: Martin Cerveny Cc: Jürgen Groß, xen-devel, Wei Liu, Chunyan Liu, Fabio Fantoni, Anthony Perard, Simon Cao On Wed, Apr 27, 2016 at 7:03 PM, Martin Cerveny <martin@c-home.cz> 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-27 18:03 ` Martin Cerveny 2016-04-28 8:35 ` George Dunlap @ 2016-04-28 14:20 ` Fabio Fantoni 2016-04-28 16:33 ` Martin Cerveny 1 sibling, 1 reply; 8+ messages in thread From: Fabio Fantoni @ 2016-04-28 14:20 UTC (permalink / raw) To: Martin Cerveny Cc: jgross, xen-devel, Wei Liu, George.Dunlap, George Dunlap, cyliu, Anthony.Perard, caobosimon 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, 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@lists.xen.org >> http://lists.xen.org/xen-devel >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-28 14:20 ` Fabio Fantoni @ 2016-04-28 16:33 ` Martin Cerveny 2016-04-29 9:34 ` Fabio Fantoni 0 siblings, 1 reply; 8+ messages in thread From: Martin Cerveny @ 2016-04-28 16:33 UTC (permalink / raw) To: Fabio Fantoni Cc: jgross, xen-devel, Wei Liu, George.Dunlap, George Dunlap, cyliu, Martin Cerveny, Anthony.Perard, caobosimon 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@lists.xen.org >>> http://lists.xen.org/xen-devel >>> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels 2016-04-28 16:33 ` Martin Cerveny @ 2016-04-29 9:34 ` Fabio Fantoni 0 siblings, 0 replies; 8+ messages in thread From: Fabio Fantoni @ 2016-04-29 9:34 UTC (permalink / raw) To: Martin Cerveny Cc: jgross, xen-devel, Wei Liu, George.Dunlap, George Dunlap, cyliu, Anthony.Perard, caobosimon Il 28/04/2016 18:33, Martin Cerveny ha scritto: > > > 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. This is strange, in production using the other method (spice) and in testing I did days ago I used usb2 controller, I tested usb3 controller when I did the usbversion patch and was working with both linux and windows 7 domUs (windows require install usb3 drivers before). The only problem I had was with usb1 controller on windows (that seems was a windows problem). Usb3 controller is compatible with usb1 and usb2 devices without addition FWIK and based on what qemu developers told me, usb2 controller instead need addition (seems my usbversion patch in libxl for example) When I'll have enoght time I'll complete the small experimental libxl patch, now I did only the qmp functions, I must add at least minimal code for basic xl commands. After I'll do many fast tests in short time (including with usb3 controller). My experimental patch is/will be here: https://github.com/Fantu/Xen/commits/hvm-improve.t16 Any comment/advice is appreciated. > > 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@lists.xen.org >>>> http://lists.xen.org/xen-devel >>>> >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-04-29 9:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-27 11:02 Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels Fabio Fantoni 2016-04-27 11:26 ` George Dunlap 2016-04-27 15:35 ` Fabio Fantoni 2016-04-27 18:03 ` Martin Cerveny 2016-04-28 8:35 ` George Dunlap 2016-04-28 14:20 ` Fabio Fantoni 2016-04-28 16:33 ` Martin Cerveny 2016-04-29 9:34 ` Fabio Fantoni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).