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

[Hans de Goede]

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]

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