[Qemu-devel] usb descriptor parsing, why bother?

[Qemu-devel] usb descriptor parsing, why bother?

[David Fries]

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 <kraxel@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 <david@fries.net>    PGP pub CB1EE8F0
http://fries.net/~david/

Re: [Qemu-devel] usb descriptor parsing, why bother?

[Gerd Hoffmann]

On 05/12/12 03:32, David Fries wrote:
> 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 <kraxel@redhat.com>
> Date:   Thu Mar 29 16:06:28 2012 +0200
> usb-host: rewrite usb_linux_update_endp_table

Yea, that one should fix it ;)

> 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.

No.  It uses the wMaxPacketSize to pick a useful buffer size for iso
endpoints.  In master / upcoming 1.1 usb-host enables pipelining for
bulk endpoints.

Beside that enabling the usb_host_parse_* tracepoints gives a useful
trace of guest activities (you should see your guest picking alt #3).

cheers,
  Gerd