From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45001 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNlY7-0002eo-QK for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:12:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNlY6-0000LY-LV for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:12:39 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:48459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNlY6-0000KM-9U for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:12:38 -0500 From: Paul Brook Subject: Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice? Date: Wed, 1 Dec 2010 12:12:34 +0000 References: <29465206.14.1291043417418.JavaMail.root@zimbra.grelot.net> <201012011104.57988.paul@codesourcery.com> <4CF63641.6050609@redhat.com> In-Reply-To: <4CF63641.6050609@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012011212.34772.paul@codesourcery.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 > >>>> usb_add net:192.168.1.100:2222:[vid]:[pid] > >>>> or: > >>>> usb_add net:192.168.1.100:2222:[busnr]:[addr] > > ... > > 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. Except that by having a way of specifying the remote device you are implicitly including some form management interface. However... > 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. This sounds reasonable. On a tangential note, it's worth considering whether we want to support passthrough of a hub (including all connected devices). My suspicion is this may be more trouble than it's worth. Instead make this the responsibility of the management layer. If we want to create the appearance of a physical hub being connected to a VM, then the management layer should leave the hub itself alone and automatically passthrough all the individual downstream devices. Paul