Re: [Qemu-devel] Re: [Spice-devel] RFC; usb redirection protocol

[Alon Levy <alevy@redhat.com>]

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: <sizeof usb device descriptors>
> >>
> >>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
>