Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Paul Brook <paul@codesourcery.com>]

> >>>> 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:<host:port>:[device_id]
> 
> Becomes just:
>      net:<host:port>
> 
> 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