Hello USB folks,
I 'm looking into improving the usb pass-through support in qemu /
kvm. A (well-known as it seems) problem
with that is devices that want to switch configuration, perform resets
as part of their initialization etc. In short,
all the problems that Vmware and Xen had.
I 've read the discussion threads with Chris Li (vmware) last year and
with Harry Butterworth (xen) a couple
years before, but I can't figure out if there was a final decision (or
an implementation) of how these issues
should be solved.
In my understanding, the common theme is that there is a need for
userspace to have a way to "grab"
exclusively a full usb device (not just an interface) or even better,
a port. As soon as the grab succeeds,
the device/port become mostly hidden from the normal kernel
enumeration mechanisms and also inaccessible
to other userspace programs. (reads from attribute files may succeed,
but changing configuration / ioctls
should fail).
This would allow one to e.g., start qemu with
qemu -usbdevice host:auto:3.* (3 is a
bus number)
and make sure the device stays bound to qemu even if the device wants
to perform a reset as part of its
init sequence (e.g., the FX2 devices tend to do that, like my
Hauppauge winpvr usb2).
Possible users of such a feature:
* Qemu / KVM
* Xen PvUSB (it would allow them to drop their "stub driver").
* USB/IP (likewise).
* Vmware / Virtualbox (if those haven't found another solution yet).
Has this problem already been solved?
Thanks in advance,
Pantelis
P.S., note that it would be fine for my usecase if the user has to
unplug the device, turn it off even
and replug it after the port is "grabbed" to make sure the device is
in a clean state.
That is still much better than the device not working at all, or
having to mess around with kernel internals etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
