From: David Fries <david@fries.net>
To: qemu-devel@nongnu.org
Cc: Gerd Hoffmann <kraxel@redhat.com>
Subject: [Qemu-devel] usb descriptor parsing, why bother?
Date: Fri, 11 May 2012 20:32:46 -0500 [thread overview]
Message-ID: <20120512013246.GP3011@spacedout.fries.net> (raw)
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/
next reply other threads:[~2012-05-12 1:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-12 1:32 David Fries [this message]
2012-05-14 7:30 ` [Qemu-devel] usb descriptor parsing, why bother? Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120512013246.GP3011@spacedout.fries.net \
--to=david@fries.net \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).