From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46646 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNl8W-0002VI-Mq for qemu-devel@nongnu.org; Wed, 01 Dec 2010 06:46:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNl8V-0001A1-6Z for qemu-devel@nongnu.org; Wed, 01 Dec 2010 06:46:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNl8U-00019c-W7 for qemu-devel@nongnu.org; Wed, 01 Dec 2010 06:46:11 -0500 Message-ID: <4CF63641.6050609@redhat.com> Date: Wed, 01 Dec 2010 12:49:21 +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> <20101130113230.GD12522@playa.tlv.redhat.com> <4CF4ECAB.9010602@redhat.com> <201012011104.57988.paul@codesourcery.com> In-Reply-To: <201012011104.57988.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: spice-devel@lists.freedesktop.org, qemu-devel@nongnu.org Hi, On 12/01/2010 12:04 PM, Paul Brook wrote: >> Hi, >> >> On 11/30/2010 12:32 PM, Alon Levy wrote: >>> On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote: >> >> >>>> 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? >> >> The idea is one channel (one socket in this case), one device. This way the >> same server on the usb-host could export multiple devices, using one >> client connection per device. The server of course should in the end have >> some sort of security wrt which devices the vm-host can connect to and >> which not. > > I don't think either of vid:pid or bus:address are a good idea for identifying > remote devices. The idea that the VM should need to know about the details of > the USB topology of the remote machine seems fundamentally wrong. It also > means that it's impossible to use devices that reset+reconnect themselves. > > Instead I suggest just using a freeform string ID. For practical reasons we > probably want to restrict this to regular characters, like we do other ids > (i.e. [-_A-Za-z0-9]). This allows the device server to assign persistent, > meaningful names to devices. If you really want to allow the VM free reign of > devices on a machine you can just make it the server accept and parse names of > the form device_id_1234_5678 (for example). > > For bonus points your protocol should include some way of enumerating the > available devices. > First of all management (enumeration, requesting a specific device) is something which I want to do separately from the usb redirection protocol itself as management is transport specific, see below. > When tunneling over spice/vnc I'd expect the same id to be used. i.e. > net::[device_id] > spice:[sice_display]:[device_id] > vnc:[vnc_display>]:[device_id] In the spice and vnc cases I do not expect there to be a way to connect to devices on the client from the monitor. Instead the client will tell qemu through some sort of command channel, that there is a remote usb device to be plugged into the virtual machine through redirection. This is what makes most sense from a use case pov. A user is sitting behind some client machine connecting to a vm through vnc / spice and then wants to "plug" some local (to the client machine) usb device into the vm. The logical way to do this is through some menu / other UI part of the vnc / spice client. This menu would then show a list of all currently connected devices and allow the user to choose one to plug in. The problem with exotic devices which disconnect and come back under a different guise then also becomes a client problem, which is IMHO where it belongs (the client could for example remember which usb-port it is redirecting to the virtual machine and if a device unplug / replug happens there also redirect the new device). Thinking more about this, the solution to the whole device id problem is not sending a device id from qemu / the monitor at all, iow: net::[device_id] Becomes just: net: In this scenario a server already needs to be started manually on the usb-host, the device / port to share can then be indicated when starting the server. And in the rare case one wants to share multiple devices/ports on the same usb-host one can simply start the server multiple times listening on different ports. Regards, Hans