From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45351 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNevm-0007Hq-5J for qemu-devel@nongnu.org; Wed, 01 Dec 2010 00:09:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNO0J-0005EY-KK for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:04:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNO0J-0005Av-9V for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:04:11 -0500 Message-ID: <4CF4DAE8.800@redhat.com> Date: Tue, 30 Nov 2010 12:07:20 +0100 From: Hans de Goede MIME-Version: 1.0 References: <20101129101727.2B64E2B679@zimbra14-e2.priv.proxad.net> <1C05A6E3-D458-43C4-9DF0-4371FC157FF5@free.fr> <4CF3CB17.6000306@redhat.com> In-Reply-To: <4CF3CB17.6000306@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Using usbip for usb network redirection (was RFC: usb redirection over the network, interesting outside of spice?) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: spice-devel@lists.freedesktop.org, =?ISO-8859-1?Q?Fran=E7ois_Revol?= , qemu-devel@nongnu.org Hi, First some definitions: vm-host: machine running the qemu virtual machine with the guest os usb-host: machine which has the usb device which "appears" inside the vm On 11/29/2010 04:47 PM, Gerd Hoffmann wrote: > Hi, > >> Not me at the moment, but unless you tunnel it inside another >> protocol, you'd really want to look at the existing USB-over-IP >> protocols instead of reinventing the wheel: >> http://usbip.sourceforge.net/ (some support in Linux already IIRC) >> (and there are others which I don't recall) > > Doesn't look very useful on a quick glance. > I already was aware of usbip and had looking into it on my todo. As multiple people have pointed out the existence and possible o.t.s. usage of usbip I've spend some time taking a (much) closer look at usbip, esp. At the protocol it uses. > First: Yes, we wanna embed this into other protocol(s). Well, we could do that with the current usbip protocol as long as we create a virtual channel for it inside those other protocols > Second, seems usbip is implemented using special drivers in kernel space for both sides. We will not need special drivers on the qemu side (we just hook up the devices to the emulated hci). On the client side using libusb looks alot more sensible than requiring kernel modules. Agreed. Note though that there already is a libusb using implementation for the software running on the usb-host (what you call client and the usbip people call server). As for the vm-host, yes we cannot reuse the usbip software there, but talking the same protocol as them would still be good, as that allows re-using the usbip usb-host software. Still overall I agree with you that usbip is not very useful: 1) It is dead upstream 2) The libusb version of the usb-host software is quite ugly code (as the author admits it is a quick hack developed according to the test it, fix it, test it, till it works cycle). 3) The protocol itself is far from ideal. Number 3 is the big deal breaker for me. I've looked at the (undocumented) protocol by sifting through the source. And it is very low level, all it does is shove usb packets back and forth over the network. It has no concept of configuration setting (the docs say make sure the device is in the right configuration before sharing it). No concept of caching things like descriptors, active configuration, per interface alt setting, etc. Besides missing a lot of useful smarts the whole one packet at a time approach does not really fly when it comes to isoc endpoints. As there paper states, the vm-host / guest os drivers need to make sure enough packets are submitted / queued at all time to gap the network delay / fill the network pipe. For iso endpoints it makes much more sense to have a start / stop stream model, where the usb-host "pumpes" the urb ringbuffer and sends out data received from the usb device to the vm-host (isoc input endp case), or sends data received from the vm-host (through a buffer to deal with network jitter) to the isoc output endpoint. This also halves the number of packets which need to be send over the network, as their is no need for the vm-host to send a request for each packet once an input stream has started / for the usb-host to send an ack for each delivered packet for an ouput stream. It would still send an error when an error occurs, but their is no reason to ack all delivered packets. Given the delay caused by buffering, etc. not being able to match up the error to an exact packet is not important, as from the vm-host emulated usb hc (host controller), the packet has long been delivered already. Instead we will simply report the error to the guest os for the next packet enqueued by the guest after receiving notification of the error from the usb-host. Regards, Hans