Re: [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
> address@hidden
> http://lists.freedesktop.org/mailman/listinfo/spice-devel