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

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

[François Revol]

> 
> Hi All,
> 
> Now that I have usb-1.1 passthrough  / local redirection support
> working reliably (see my patch sets for this), I'm going to start
> working on doing usb redirection support over the network.
> 
> The idea here is that a usb device connected to machine a, will be
> available for use by the guest os running on host b (machine b).
> 
> I'm working on this because it is something which we want / need
> for spice. I'm wondering if there is interest in this outside
> of spice ?

Not me at the moment, but unless you tunnel it inside another protocol, you'd really want to look at the existing USB-over-IP protocols instead of reinventing the wheel:
http://usbip.sourceforge.net/ (some support in Linux already IIRC)
(and there are others which I don't recall)

> I'm asking because at this moment in time the redirection support
> can probably be written in a way which abstracts the transport channel
> quite easily, allowing use outside of spice.

Yeah it'd be nice to avoid code duplication.

Does RDP have such feature ?
I'd think it should be possible to add this to VNC somehow, since it has provisions for extensions.

François.

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

[Gerd Hoffmann]

   Hi,

> Not me at the moment, but unless you tunnel it inside another
> protocol, you'd really want to look at the existing USB-over-IP
> protocols instead of reinventing the wheel:
> http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> (and there are others which I don't recall)

Doesn't look very useful on a quick glance.

First: Yes, we wanna embed this into other protocol(s).

Second, seems usbip is implemented using special drivers in kernel space 
for both sides.  We will not need special drivers on the qemu side (we 
just hook up the devices to the emulated hci).  On the client side using 
libusb looks alot more sensible than requiring kernel modules.

cheers,
   Gerd

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

[Frédéric Grelot]

> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 

I'm note sure about what I will say, but will a kernel approach handle specific disconnection/reconnection of devices, that libusb cannot?

I'm thinking in particular of what happens when one updates an iP* (*=hone, ad, odTouch, od) device, where it gets connected and disconnected several times during the process. 
During the updates, the device reboots, generating a disconnection event, and at reboot the guest OS (and iTunes) has to  to catch the reconnection event directly (before iOS loads) to upload the new firmware.
I'm not sure about it, but I think Virtualbox (non-ose) took care of this issue, and updates are now possible in a vm (TbC).

I don't think that an approach at libusb level would work, while I could understand that a kernel module would be able to catch the "connection" event directly, and pipe it through the network to the guest.

I don't know for sure if this use case affects only those devices, nor if it is an objective for spice to allow Apple device updates, but I think it has to be handled at pretty low level, so is worth mentioning before any implementation choices.
Still, if such thing were to work, I think it would be a huge step for all the people in the iP* community that maintain a double boot only because they bought a closed phone once :-)

However, the guest side could be handled at qemu-level, since it would certainly provide an OS-independent implementation without the need for linux-/windows-/other-specific driver.

Frederic.

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

[Gerd Hoffmann]

   Hi,

> I'm note sure about what I will say, but will a kernel approach
> handle specific disconnection/reconnection of devices, that libusb
> cannot?

Don't know, didn't investigate (yet) what libusb can do and what it can't.

cheers,
   Gerd

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

[Attila Sukosd]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Hi,

I guess it should be abstract enough to support multiple back-ends, be it a
kernel driver or through libusb?


Rgrds,

Attila


2010/11/29 Gerd Hoffmann <kraxel@redhat.com>

>  Hi,
>
>
>  I'm note sure about what I will say, but will a kernel approach
>> handle specific disconnection/reconnection of devices, that libusb
>> cannot?
>>
>
> Don't know, didn't investigate (yet) what libusb can do and what it can't.
>
> cheers,
>  Gerd
>
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>

[-- Attachment #2: Type: text/html, Size: 1363 bytes --]

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

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

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.

What is unclear to me is what role QEMU would play in setting up remove 
USB-over-IP devices.  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.

Regards,

Anthony Liguori

>
> Rgrds,
>
> Attila
>
>
> 2010/11/29 Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>>
>
>      Hi,
>
>
>         I'm note sure about what I will say, but will a kernel approach
>         handle specific disconnection/reconnection of devices, that libusb
>         cannot?
>
>
>     Don't know, didn't investigate (yet) what libusb can do and what
>     it can't.
>
>     cheers,
>      Gerd
>
>
>
>     _______________________________________________
>     Spice-devel mailing list
>     Spice-devel@lists.freedesktop.org
>     <mailto:Spice-devel@lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>


[-- Attachment #2: Type: text/html, Size: 2678 bytes --]

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

[Alexander Graf]

On 29.11.2010, at 18:49, 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.
> 
> What is unclear to me is what role QEMU would play in setting up remove USB-over-IP devices.  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.

I agree. And if by any chance the libusb interfaces don't cut it, we should just enhance libusb.


Alex

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

[Gerd Hoffmann]

On 11/29/10 18:49, 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.
>
> What is unclear to me is what role QEMU would play in setting up remove
> USB-over-IP devices.  Pushing it down to the libusb layer completely
> takes QEMU out the picture which creates a clean separation layer.

Well, I think the management is actually the most tricky thing here. 
Unfortunaly this isn't covered very well in the usb/ip papers.  Also 
there seems to be no protocol specification linked from the website.

Being compatible at protocol level makes sense for direct connections 
(if possible).  For the usb-over-vnc and vnc-over-spice cases this 
probably isn't going to work though.

cheers,
   Gerd

Re: [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

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

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

[Hans de Goede]

Hi,

On 11/30/2010 12:32 PM, Alon Levy wrote:
> On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:

<snip snip>

>> 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?
>

The idea is one channel (one socket in this case), one device. This way the same
server on the usb-host could export multiple devices, using one client connection
per device. The server of course should in the end have some sort of security wrt
which devices the vm-host can connect to and which not.

Regards,

Hans

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

[Paul Brook]

> Hi,
> 
> On 11/30/2010 12:32 PM, Alon Levy wrote:
> > On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
> <snip snip>
> 
> >> 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?
> 
> The idea is one channel (one socket in this case), one device. This way the
> same server on the usb-host could export multiple devices, using one
> client connection per device. The server of course should in the end have
> some sort of security wrt which devices the vm-host can connect to and
> which not.

I don't think either of vid:pid or bus:address are a good idea for identifying 
remote devices.  The idea that the VM should need to know about the details of 
the USB topology of the remote machine seems fundamentally wrong. It also 
means that it's impossible to use devices that reset+reconnect themselves.

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.

When tunneling over spice/vnc I'd expect the same id to be used. i.e.
  net:<host:port>:[device_id]
  spice:[sice_display]:[device_id]
  vnc:[vnc_display>]:[device_id]

Paul

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

[Hans de Goede]

Hi,

On 12/01/2010 12:04 PM, Paul Brook wrote:
>> Hi,
>>
>> On 11/30/2010 12:32 PM, Alon Levy wrote:
>>> On Tue, Nov 30, 2010 at 12:26:56PM +0100, Hans de Goede wrote:
>> <snip snip>
>>
>>>> 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?
>>
>> The idea is one channel (one socket in this case), one device. This way the
>> same server on the usb-host could export multiple devices, using one
>> client connection per device. The server of course should in the end have
>> some sort of security wrt which devices the vm-host can connect to and
>> which not.
>
> I don't think either of vid:pid or bus:address are a good idea for identifying
> remote devices.  The idea that the VM should need to know about the details of
> the USB topology of the remote machine seems fundamentally wrong. It also
> means that it's impossible to use devices that reset+reconnect themselves.
>
> 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.

> When tunneling over spice/vnc I'd expect the same id to be used. i.e.
>    net:<host:port>:[device_id]
>    spice:[sice_display]:[device_id]
>    vnc:[vnc_display>]:[device_id]

In the spice and vnc cases I do not expect there to be a way to connect
to devices on the client from the monitor. Instead the client will tell
qemu through some sort of command channel, that there is a remote usb
device to be plugged into the virtual machine through redirection.

This is what makes most sense from a use case pov. A user is sitting
behind some client machine connecting to a vm through vnc / spice and
then wants to "plug" some local (to the client machine) usb device
into the vm. The logical way to do this is through some menu / other
UI part of the vnc / spice client. This menu would then show a list of
all currently connected devices and allow the user to choose one to
plug in.

The problem with exotic devices which disconnect and come back under
a different guise then also becomes a client problem, which is IMHO
where it belongs (the client could for example remember which usb-port
it is redirecting to the virtual machine and if a device unplug /
replug happens there also redirect the new device).

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.

And in the rare case one wants to share multiple devices/ports on the same
usb-host one can simply start the server multiple times listening on
different ports.

Regards,

Hans

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

[Paul Brook]

> >>>> 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

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

[François Revol]

>>> The idea here is that a usb device connected to machine a, will be
>>> available for use by the guest os running on host b (machine b).
>>> 
>>> I'm working on this because it is something which we want / need
>>> for spice. I'm wondering if there is interest in this outside
>>> of spice ?
>>> I'm asking because at this moment in time the redirection support
>>> can probably be written in a way which abstracts the transport channel
>>> quite easily, allowing use outside of spice.
[...]
>> Not me at the moment, but unless you tunnel it inside another
>> protocol, you'd really want to look at the existing USB-over-IP
>> protocols instead of reinventing the wheel:
>> http://usbip.sourceforge.net/ (some support in Linux already IIRC)
>> (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 
> First: Yes, we wanna embed this into other protocol(s).
> 
> Second, seems usbip is implemented using special drivers in kernel space for both sides.  We will not need special drivers on the qemu side (we just hook up the devices to the emulated hci).  On the client side using libusb looks alot more sensible than requiring kernel modules.

I recall seeing discussions about it on the libusb-devel list (CCing).

http://search.gmane.org/?query=usbip&group=gmane.comp.lib.libusb.devel.general

It's just one implementation of it, it should be possible to implement a subset of the features at least with libusb which should be enough for most devices (scanners/printers/mass storage). 

And it's better to use the same protocol anyway when possible.
This way the untunnelled version could be used from QEMU or a host using a stub driver connecting to a server using either the kernel driver or the libusb version regardless.

François.

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

[Peter Stuge]

François Revol wrote:
> > usbip

I don't know how good this is.

For another implementation of USB-over-IP you could look at Sun's
work with the SunRay thin clients. I believe some of it may be in
the OpenUSB codebase. (They forked libusb to make it work the way
they wanted.) I don't know how good that is, either.


> > On the client side using libusb looks alot more sensible than
> > requiring kernel modules.
..
> It's just one implementation of it, it should be possible to
> implement a subset of the features at least with libusb which
> should be enough for most devices (scanners/printers/mass storage).

Keep in mind that libusb can be used only with USB interfaces which
have the usbfs driver bound to them. (Or no driver at all, in which
case usbfs is transparently bound at libusb_claim_interface() time.)

This means that any kernel driver (like usb-storage) must be moved
out of the way. This can be done with libusb, but not portably. Given
sufficient permissions it works nicely and on the fly in Linux, but
Mac OS X needs manual work and a reboot, and Windows needs to create
a restore point. On Windows the libwdi library can be used to switch
drivers for USB interfaces. http://libusb.org/wiki/libwdi

I have been mulling over if libusb should actually take on the
significant task of USB kernel driver management, offering a portable
API also for that. In principle I would very much prefer not to do
this within libusb, but it is relevant because libusb does require
that special kernel driver. Unfortunately it is so painful outside
Linux.


> And it's better to use the same protocol anyway when possible.
> This way the untunnelled version could be used from QEMU or a host
> using a stub driver connecting to a server using either the kernel
> driver or the libusb version regardless.

I doubt USB-over-IP is a good enough USB transport for QEMU. I think
QEMU will want lower level access to the bus. One way is to leverage
libusb, but even that might not be good enough in the long run.


//Peter

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

[Paul Brook]

>    Hi,
> 
> > Not me at the moment, but unless you tunnel it inside another
> > protocol, you'd really want to look at the existing USB-over-IP
> > protocols instead of reinventing the wheel:
> > http://usbip.sourceforge.net/ (some support in Linux already IIRC)
> > (and there are others which I don't recall)
> 
> Doesn't look very useful on a quick glance.
> 
> First: Yes, we wanna embed this into other protocol(s).
> 
> Second, seems usbip is implemented using special drivers in kernel space
> for both sides.  We will not need special drivers on the qemu side (we
> just hook up the devices to the emulated hci).  On the client side using
> libusb looks alot more sensible than requiring kernel modules.

I don't know how good the usp/ip stuff is, but I'd be very reluctant to invent 
yet annother remote-usb protocol.  USB is very hairy, so there's good reason 
to go with something that has already been tested.

IMO the ability to interact with the native kernel support is a feature in its 
own right.  If we end up with a libusb implementation of the usb/ip device 
end, then that only seems like a good thing - you potentialy get testing 
coverage from both qemu users and native vhci-hcd users.

Paul

[Qemu-devel] Using usbip for usb network redirection (was RFC: usb redirection over the network, interesting outside of spice?)

[Hans de Goede]

Hi,

First some definitions:

vm-host:  machine running the qemu virtual machine with the guest os
usb-host: machine which has the usb device which "appears" inside the vm

On 11/29/2010 04:47 PM, Gerd Hoffmann wrote:
> Hi,
>
>> Not me at the moment, but unless you tunnel it inside another
>> protocol, you'd really want to look at the existing USB-over-IP
>> protocols instead of reinventing the wheel:
>> http://usbip.sourceforge.net/ (some support in Linux already IIRC)
>> (and there are others which I don't recall)
>
> Doesn't look very useful on a quick glance.
>

I already was aware of usbip and had looking into it on my todo.
As multiple people have pointed out the existence and possible o.t.s.
usage of usbip I've spend some time taking a (much) closer look at
usbip, esp. At the protocol it uses.

> First: Yes, we wanna embed this into other protocol(s).

Well, we could do that with the current usbip protocol as
long as we create a virtual channel for it inside those
other protocols

> Second, seems usbip is implemented using special drivers in kernel space for both sides. We will not need special drivers on the qemu side (we just hook up the devices to the emulated hci). On the client side using libusb looks alot more sensible than requiring kernel modules.

Agreed. Note though that there already is a libusb using
implementation for the software running on the usb-host (what you
call client and the usbip people call server).

As for the vm-host, yes we cannot reuse the usbip software there,
but talking the same protocol as them would still be good, as
that allows re-using the usbip usb-host software.


Still overall I agree with you that usbip is not very useful:
1) It is dead upstream
2) The libusb version of the usb-host software is quite ugly code
    (as the author admits it is a quick hack developed according to
     the test it, fix it, test it, till it works cycle).
3) The protocol itself is far from ideal.

Number 3 is the big deal breaker for me. I've looked at the
(undocumented) protocol by sifting through the source. And it is
very low level, all it does is shove usb packets back and forth
over the network. It has no concept of configuration
setting (the docs say make sure the device is in the right
configuration before sharing it). No concept of caching things
like descriptors, active configuration, per interface alt setting,
etc.

Besides missing a lot of useful smarts the whole one packet at a
time approach does not really fly when it comes to isoc endpoints.
As there paper states, the vm-host / guest os drivers need to
make sure enough packets are submitted / queued at all time
to gap the network delay / fill the network pipe.

For iso endpoints it makes much more sense to have a start / stop
stream model, where the usb-host "pumpes" the urb ringbuffer and
sends out data received from the usb device to the vm-host
(isoc input endp case), or sends data received from the vm-host
(through a buffer to deal with network jitter) to the isoc output
endpoint.

This also halves the number of packets which need to be
send over the network, as their is no need for the vm-host to send
a request for each packet once an input stream has started / for
the usb-host to send an ack for each delivered packet for an ouput
stream. It would still send an error when an error occurs, but their
is no reason to ack all delivered packets. Given the delay
caused by buffering, etc. not being able to match up the error to
an exact packet is not important, as from the vm-host emulated usb
hc (host controller), the packet has long been delivered already.

Instead we will simply report the error to the guest os for the
next packet enqueued by the guest after receiving notification of
the error from the usb-host.

Regards,

Hans