All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
To: George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xensource.com
Cc: jgross@suse.com, Wei Liu <wei.liu2@citrix.com>,
	George.Dunlap@eu.citrix.com, cyliu@suse.com,
	Anthony.Perard@citrix.com, caobosimon@gmail.com
Subject: Re: Questions about the new usb hotplug code in libxl and about adding hotplug (with qmp) usbredir tcp channels
Date: Wed, 27 Apr 2016 17:35:58 +0200	[thread overview]
Message-ID: <5720DC5E.8000307@m2r.biz> (raw)
In-Reply-To: <5720A1FB.1030504@citrix.com>

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

  reply	other threads:[~2016-04-27 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5720DC5E.8000307@m2r.biz \
    --to=fabio.fantoni@m2r.biz \
    --cc=Anthony.Perard@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=caobosimon@gmail.com \
    --cc=cyliu@suse.com \
    --cc=george.dunlap@citrix.com \
    --cc=jgross@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.