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

[Hans de Goede]

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.

Regards,

Hans