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