From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51415 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSt7h-0003x1-I2 for qemu-devel@nongnu.org; Wed, 15 Dec 2010 10:18:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSt7b-00032U-5O for qemu-devel@nongnu.org; Wed, 15 Dec 2010 10:18:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSt7a-00032J-Sn for qemu-devel@nongnu.org; Wed, 15 Dec 2010 10:18:27 -0500 Date: Wed, 15 Dec 2010 17:18:21 +0200 From: Alon Levy Subject: Re: [Qemu-devel] Re: [Spice-devel] RFC; usb redirection protocol Message-ID: <20101215151820.GE21233@playa.redhat.com> References: <4D0234D9.7040806@redhat.com> <4D0601CF.6080007@redhat.com> <4D08B17E.90100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D08B17E.90100@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: spice-devel@lists.freedesktop.org, Gerd Hoffmann , qemu-devel@nongnu.org On Wed, Dec 15, 2010 at 01:15:58PM +0100, Hans de Goede wrote: > Hi, > > Thanks for taking the time to read all that! > > On 12/13/2010 12:21 PM, Gerd Hoffmann wrote: > >>Basic packet structure / communication > >>-------------------------------------- > >> > >>Each packet exchanged between the vm-host and the usb-host starts > >>with a usb_redir_header, followed by an optional command specific > >>header follow by optional additional data. > >> > >>The usb_redir_header each packet starts with looks as follows: > >> > >>struct usb_redir_header { uint32_t command; uint32_t length; } > > > >uint32_t id; ? A reply would then carry the id of the request ... > > > > That sounds like a good idea (all though for iso streams the packets > will be only send in one direction). > > >>Given that everything is done over a potentially slow transport in > >>practice the diferentiating between synchroneous and asynchroneous > >>commands may seem odd. The difference is how the usb-host will handle > >>them once received. For synchroneous commands the usb-host will hand > >>the request over to the host os and then *wait* for a response. This > >>means that the vm-host is guaranteed to get an "immediate" response. > >>Where as for asynchroneous commands to usb-host hands the request > >>over to the host os with the request to let the usb-host process know > >>when the request is done. > > > >Hmm. Looks like you are planning for one tcp stream and one thread (on the usb-host side) for each usb device. That will not work very good for usb-over-vnc because there is a single tcp stream only. We could of course multiplex multiple logical usb connections over vnc, but even then blocking on the usb-host side looks bad as this could disrupt other usb devices forwarded over the same connection. > > The idea is for this protocol to be transport independent (*) so it > could be one stream, or it could be multiplexed into another transport. > > Assuring that there are not too large latencies, and handling things > like not blocking for too long when handling multiple devices from the > same thread are left to the implementation. > > It could be that the implementation decides to not handle synchroneous > commands synchroneous at all. The main difference I'm trying to make > here is between commands which do things to end points which cannot > be done while other packets are in flight (like setting configuration, > or interface alt setting) and commands (normal packets) of which there > can be multiple in flight. I'm open to using a different term then > synchroneous and async here. > > *) Assuming a reliable, ordered transport > > > > >>usb_redir_report_descriptor --------------------------- > >> > >>usb_redir_header.command: usb_redir_report_desciptor > >>usb_redir_header.length: > >> > >>No command specific header. > >> > >>The command specific additional data contains the entire descriptors > >>for the usb device. > >> > >>A packet of this type is send by the usb-host directly after the > >>hello packet it contains the usb descriptor tables for the usb > >>device. > > > >Device addressing isn't done at all in the protocol, i.e. there is a fixed device <-> connection relation ship? > > > > The idea is there is a fixed device <-> transport pipe relation ship, yes. > For the simple tcp server usb-host I plan to implement as first usb-host, > the device would be specified on the cmdline while starting the server. > > When one wants to use multiple devices, this means starting one usb-server > per device. > > For things like vnc and spice I assume there will be some sort of control > channel where usb device management is done. To be more precise I expect > the vnc client / spice client to have some UI which allows selecting a usb > device to plug into the virtual machine. And then the client will setup a > transport for this (reserve a channel within its existing stream) and tell > the server that it has an usb device at sub channel id #, at which point > the server will add a new usb redir device to qemu, passing in a transport > "object" which is connected to this channel. > > >>Please let me know what you think of this. > > > >Do you know whenever certain low-level usb ops can work with this? > > > > I expect most usb devices to work with this, I don't know about > really weird ones. > > >Specifically iphone firmware flashing was mentioned on the list. > > > > I think that should work, but that is an interesting case about which > I don't know enough yet. > > >Also I remember somewhere in the ehci (or xhci?) specs was mentioned > > with some devices it can be needed to talk to them *before* an bus address is assigned ... > > If some devices need this, and the setup done there cannot be done > by the client machines os, we loose, as device enumeration and address > assignment is done at the OS level, and at least under Linux we won't > get a chance to talk to the device till after it has been assigned an > address. > I know of devices that will enumerate twice, first as one device, then after a certain setup exchange as another. But that seems to be covered by the suggestion here, it will just be identicle to two completely different transports. > Regards, > > Hans >