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

[Alon Levy]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel