qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: [Qemu-devel] Re: [Spice-devel] RFC; usb redirection protocol
Date: Mon, 13 Dec 2010 12:21:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100827 Red Hat/3.1.3-1.el6 Thunderbird/3.1.3

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]