From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38867 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PS6Te-0005OO-Ni for qemu-devel@nongnu.org; Mon, 13 Dec 2010 06:22:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PS6Td-0000u1-IE for qemu-devel@nongnu.org; Mon, 13 Dec 2010 06:21:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PS6Td-0000tl-BV for qemu-devel@nongnu.org; Mon, 13 Dec 2010 06:21:57 -0500 Message-ID: <4D0601CF.6080007@redhat.com> Date: Mon, 13 Dec 2010 12:21:51 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4D0234D9.7040806@redhat.com> In-Reply-To: <4D0234D9.7040806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [Spice-devel] RFC; usb redirection protocol List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: spice-devel@lists.freedesktop.org, qemu-devel@nongnu.org > 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: > > 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