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
Post by Gerd HoffmannHi,
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
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.
Post by Gerd HoffmannFirst: 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
Post by Gerd HoffmannSecond, 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