From: Anthony Liguori <anthony@codemonkey.ws>
To: TJ <one.timothy.jones@gmail.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Fwd: [PATCH v2] Guest OS hangs on usb_add
Date: Tue, 16 Nov 2010 13:55:04 -0600 [thread overview]
Message-ID: <4CE2E198.4020708@codemonkey.ws> (raw)
In-Reply-To: <4CE2DD27.3020608@gmail.com>
On 11/16/2010 01:36 PM, TJ wrote:
> On 11/16/2010 10:00 AM, Anthony Liguori wrote:
>
>> On 11/02/2010 09:51 AM, TJ wrote:
>>
>>> Doesn't look like this has ever been committed. qemu-kvm-0.13 has just arrived
>>> to the portage tree, but I am still having problems with it. I checked the git
>>> log and it's not there! Please commit.
>>>
>>>
>> One off device hacks are concerning because it's basically impossible to review.
>>
>> Why does this work on bare metal?
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
> Probably because bare metal USB 2.0 controllers don't give a damn about USB 3
> spec. :)
>
> My guess is that they ignore the device descriptor length and assume that it's
> always equal 18. Although the USB 2.0 spec doesn't explicitly say anywhere that
> it can't be more than 18. IIRC USB 3 even adds some extensions to the device
> descriptor. And since I wanted my code to be portable and USB 3 ready ;) I rely
> on the value in dev_descr_len.
>
> BTW, this patch is more than just a hack for the device in question. Without
> this patch qemu simply locks up when I attach the remote and spins in endless
> loop, because USB parsing is so very primitive. With this patch, USB parsing is
> done more intelligently and devices with whacky USB descriptors are simply rejected.
>
> The hack part is really just 3 lines:
>
>
>>> + if (dev_descr_len == 0x18&& dev->descr[ 8] == 0x47&& dev->descr[ 9] == 0x46
>>> +&& dev->descr[10] == 0x00&& dev->descr[11] == 0x30)
>>> + dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy MX-950 remote reporting len in hex */
>>>
> And it is very harmless, as all it does is overwrites the device descriptor
> length with correct one.
>
> If you don't like the hack, you can just remove the 3 lines above and use the
> rest of the patch. I will just have to remember to manually patch mine every
> time I upgrade.
>
> Your thoughts?
>
Yeah, that bit is a bit too gnarly for my tastes, but if you can resend
the rest of it with a Signed-off-by, I'd appreciate.
Regards,
Anthony Liguori
> -TJ
>
next prev parent reply other threads:[~2010-11-16 19:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-02 14:51 [Qemu-devel] Fwd: [PATCH v2] Guest OS hangs on usb_add TJ
2010-11-16 15:00 ` Anthony Liguori
2010-11-16 19:36 ` TJ
2010-11-16 19:55 ` Anthony Liguori [this message]
2011-02-23 1:20 ` TJ
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=4CE2E198.4020708@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=one.timothy.jones@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.