From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44226 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNet0-0003c7-Ic for qemu-devel@nongnu.org; Wed, 01 Dec 2010 00:06:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNORu-0001wk-Gb for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:32:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNORu-0001s8-99 for qemu-devel@nongnu.org; Tue, 30 Nov 2010 06:32:42 -0500 Date: Tue, 30 Nov 2010 13:32:31 +0200 From: Alon Levy Subject: Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice? Message-ID: <20101130113230.GD12522@playa.tlv.redhat.com> References: <29465206.14.1291043417418.JavaMail.root@zimbra.grelot.net> <4CF3D63A.60903@redhat.com> <4CF3E797.7070401@codemonkey.ws> <4CF4DF80.2090905@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF4DF80.2090905@redhat.com> 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 On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote: > 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] Wouldn't you want to add a usb_add net:host:port that would just export anything it has decided to export? or is this just the next step? > > 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 > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel