[Top][All Lists]
[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