On Sun, 3 May 2009, Pantelis Koukousoulas wrote: > 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? It has not been worked on. There was a lot of discussion, and we sort of reached a consensus about what was needed, but no patches have been posted. > 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. The earlier discussions mentioned nothing about "grabbing" ports, only "grabbing" devices. Alan Stern -- 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
