From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43809 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNeu0-0006ZV-8E for qemu-devel@nongnu.org; Wed, 01 Dec 2010 00:07:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNOJI-0003UH-L5 for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:23:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNOJI-0003Qt-BE for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:23:48 -0500 Message-ID: <4CF4DF80.2090905@redhat.com> Date: Tue, 30 Nov 2010 12:26:56 +0100 From: Hans de Goede MIME-Version: 1.0 Subject: Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice? References: <29465206.14.1291043417418.JavaMail.root@zimbra.grelot.net> <4CF3D63A.60903@redhat.com> <4CF3E797.7070401@codemonkey.ws> In-Reply-To: <4CF3E797.7070401@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, spice-devel@lists.freedesktop.org, Attila Sukosd , Gerd Hoffmann , =?UTF-8?B?RnLDqWTDqXJpYyBHcmVsb3Q=?= Hi, On 11/29/2010 06:49 PM, Anthony Liguori wrote: > On 11/29/2010 11:37 AM, Attila Sukosd wrote: >> Hi, >> >> I guess it should be abstract enough to support multiple back-ends, be it a kernel driver or through libusb? > > Is this something that should just live in libusb? > > If what libusb presented QEMU was actually implemented as USB-over-IP, QEMU wouldn't know the difference at all. I think it would also be very useful to be able for libusb-based applications to work with remote devices. > Well currently qemu is not using libusb but instead talking to usbfs directly when it comes to usb pass through. This is something worth looking into fixing (as doing the usbfs stuff ourselves is not nice), but looking at the smartcard support discussion I was left with the impression that using external libraries was deemed undesirable. Even if qemu's usb pass through code were to use libusb though, I don't think that putting network direction into libusb is a good idea though. This clearly falls outside libusb's original design goals, and would require some major work on libusb. And although libusb upstream is not entirely dead, it also is not the most alive upstream either. > What is unclear to me is what role QEMU would play in setting up remove USB-over-IP devices. That would depend on the scenario, The way I see this is we get a usb-net-redir.c which sends packets through / from a real usb device like usb-linux.c does, but then over some reliable ordered transport channel. Then there would be multiple ways to add a virtual usb device using usb-net-redir.c to the virtual machine. One way of adding such a device could be starting a tcp/ip server on a machine with an interesting usb device, say 192.168.1.100:2222 and then in the monitor type: usb_add net:192.168.1.100:2222:[vid]:[pid] or: usb_add net:192.168.1.100:2222:[busnr]:[addr] Another way would be for a spice client (viewer) to indicate through the spice main channel that it has a usb device which it wants to plug into the virtual machine, and the qemu spice code then adding this device to the vm, using a spice channel as the transport Another way would be using a vnc client and somehow one of the sides indicating they want / are providing a usb device on the vnc client machine to show up inside the vm > Pushing it down to the libusb layer completely takes QEMU out the picture which creates a clean separation layer. There are emulated devices in QEMU which we create and control and then there are passthrough devices that QEMU doesn't have any role in creating. IMHO the above 3 scenarios clearly indicates that when it comes to the device management (adding / removing) qemu needs to be involved. I plan to write and submit a RFC for the protocol over the reliable ordered transport channel today + tomorrow, and once that is in place I'll start with focussing on making it possible to do: usb_add net:192.168.1.100:2222:[vid]:[pid] Assuming that a usb device sharing server is running and ready to accept connections on 192.168.1.100:2222 Regards, Hans