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

[Gerd Hoffmann <kraxel@redhat.com>]

> 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 ...

> 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.

> 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?

> Please let me know what you think of this.

Do you know whenever certain low-level usb ops can work with this?

Specifically iphone firmware flashing was mentioned on the list.

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 ...

cheers,
   Gerd