vhci, USBIP and rabbit holes

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Hello...

For the past short while I have been fiddling with something to help me
understand USB better.

The result was changes to vhci, the virtual HCI driver (that is in
NetBSD 10.x and -current, but mostly undocumented) that made it more
complete and a USBIP test client.

Briefly, vhci is to USB what tap is to ethernet.  It provides a way to
get USB packets into and out of the system through userland.  Couple
this with a client that knows how to speak USBIP to a server and you can
have physical devices in one place and the client in another as long as
your network is fast enough.  So, for example, a Xen PV kernel can
attach to a umass device (or maybe something else) on my laptop.

One may argue that this is all a bad idea, but I won't get into that
debate.  The concept is used for a number of different reasons including
snooping on USB traffic (for example writing a device driver for a
device that has poor documentation) and software USB devices (there are
software FIDO2 keys, for example).

The rabbit hole is that I really did not intend on creating such a
thing.  I mostly just wanted to learn more about USB.

Instead of letting what I have done sit in a local tree I have placed it
in:

https://www.netbsd.org/~brad/usbip/

There are a bunch of READMEs that explain all of the parts and the code
itself (and a tar file that is everything).  The test client is probably
a large pile of rubbish, but it is just a test.


I don't have a huge number of USB devices, but what does appear to work
is USB mice and keyboards, umass(4) (including presenting a cd(4) to a
Xen PVH guest and burning a disk), axe(4), although I will admit that
presenting a NIC device over IP to a VM is a little bit odd (except for
the strange use case of making a LAN segment appear in a virtual space,
a bilocated LAN segment, perhaps???), uftdi(4) and uplcom(4).  What
might almost work is ubt(4) and maybe with some help, run(4).  Host to
device ISOCHRONOUS transfers might be working, but I could not test that
well, and device to host ISOCHRONOUS transfers are likely unsupported,
so uaudio(4) is a hit or miss and probably a miss.  I also messed with
adding the modified vhci driver to a SIMH vax, just to see how it might
work (it did a bit...).

Probably, in its current form and without more testing and work, the
vhci driver changes are not ready for commiting to the NetBSD source
tree.  I won't be working on this again, at least not for a long time as
I have run out of gas and it was a bit of a side trail anyway, but can
answer any questions someone else might have who wants to take this up.
Please read the various READMEs first, however, and expect have kernel
crashes.  It isn't hard to patch this into a 10.x or -current source
tree and if you have a handy MS-WINDOWs or Linux box to run the server
on you can try it yourself.







-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org