I was bit in kvm-qemu (Debian qemu-kvm-1.0+dfsg-11) with the usb descriptor parsing code. I was enhancing a driver in the guest and found that I could talk to usb alt 0, but not alt 3, I made a local fix and I see there is an upstream fix (listed below) in qemu.
commit 96dd9aac37d30f3425088f81523942e67b2d03ac Author: Gerd Hoffmann <kra...@redhat.com> Date: Thu Mar 29 16:06:28 2012 +0200 usb-host: rewrite usb_linux_update_endp_table I'm curious why qemu/qemu-kvm even bothers? As far as I could tell parsing the descriptor table is only used to deny the guest from submitting urbs on the wrong pipe. The guest driver shouldn't be written to submit to the wrong pipe, the guest operating system should have already parsed the usb descriptor table and prevented the request if it was on the wrong pipe, and if qemu let it go, the host should have parsed the descriptor table and rejected the transfer, so why should qemu/qemu-kvm be a fourth verifier? Alternatively if the driver was using the wrong pipe, and yet somehow was still working if running on the host, I would think it would be a more accurate emulation to let the request through, rather than guaranteeing it doesn't by blocking it. -- David Fries <da...@fries.net> PGP pub CB1EE8F0 http://fries.net/~david/