From patchwork Thu Jun 24 04:45:52 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: TJ X-Patchwork-Id: 56758 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DB22FB6F16 for ; Thu, 24 Jun 2010 15:16:29 +1000 (EST) Received: from localhost ([127.0.0.1]:52734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORena-0001Kc-AU for incoming@patchwork.ozlabs.org; Thu, 24 Jun 2010 01:16:26 -0400 Received: from [140.186.70.92] (port=35974 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OReJm-0005Yl-7A for qemu-devel@nongnu.org; Thu, 24 Jun 2010 00:45:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OReJl-0001lO-2K for qemu-devel@nongnu.org; Thu, 24 Jun 2010 00:45:38 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:40416) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OReJj-0001l2-Ti for qemu-devel@nongnu.org; Thu, 24 Jun 2010 00:45:37 -0400 Received: by vws10 with SMTP id 10so3055118vws.4 for ; Wed, 23 Jun 2010 21:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=bRAxa80o+XY8DZRItA/FxhIoz+aicCU31w4l7ml6NSE=; b=ACZ4PCCfxi9TsepEgBBbv1/gsqrH1sqz/jEGp70Ua903k98qFyjm0iC0v2ePELoKhB Jlg3qsJqCTIbSMuWjrRf6QSOCTKs9zQonorHn29oAu4NE6S45fDjC/HiHoOr3DfDjTnM CVpIWn82frwm5c/9v3XoqoRt3ZuQYeWOwIByo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=twCjC/AtviWCmTEjX1j0216dDkS/hADDqD+jnS0p8y1HLZ5sVhaZBVSVj7ZoHLxD1I EslAFQiXOrbgQXE1Wm+ZSNjKpXLvgZ4UzEHrZ2+cwS72xG4O9Rz4PWUbg3EkD8bh14lE T5VpR/OJsvO3yBsLz36BixNq7BlZNrXgehfZA= Received: by 10.220.63.143 with SMTP id b15mr4651730vci.103.1277354733131; Wed, 23 Jun 2010 21:45:33 -0700 (PDT) Received: from [192.168.0.110] ([216.7.150.90]) by mx.google.com with ESMTPS id n1sm18259676vcf.40.2010.06.23.21.45.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 21:45:32 -0700 (PDT) Message-ID: <4C22E300.5020109@gmail.com> Date: Thu, 24 Jun 2010 00:45:52 -0400 From: TJ User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100524 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: qemu-devel@nongnu.org References: In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: [Qemu-devel] Guest OS hangs on usb_add X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org > ---------- Forwarded message ---------- > From: Timothy Jones > Date: Wed, Jun 23, 2010 at 9:07 PM > Subject: Guest OS hangs on usb_add > To: qemu-devel@nongnu.org > > > With some digging around I found out that the qemu hangs in > usb_host_claim_interfaces, which is caused by screwed up usb > descriptor. The device reports the following: > > (gdb) p dev->descr_len > $21 = 50 > (gdb) p /x dev->descr[0]@50 > $23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0, > 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20, > 0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff, > 0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0, > 0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0} > > The first 0x18 (Device Descriptor bLength) is supposed to be decimal > 18, not hex! According to USB spec, if the device reports size greater > than expected, the host is supposed ignore the extra bytes. So qemu > behaves correctly here. However, with this length, the following > Configuration Descriptor length falls on a 0x0 and so the qemu spins > in an endless loop. (This is prolly something that should be detected > and reported as error by qemu.) > > My question is: This 0x18 -- is this something that comes from the > device itself (ie, firmware bug)? Or does it come from the USB > subsystem? > > I don't mind writing a small patch to make descriptor parsing a bit > more intelligent, but I am very unfamiliar with the code, so I might > botch things up. Or is the above data sufficient for one of the devs > to take a look at the code and improve it? > > Thank you. > > -TJ > Here is small patch that fixed my problem. In looking at the USB spec, it seems pretty clear cut about the whole device/config/interface/endpoint descriptor hierarchy, so the usb_host_claim_interfaces can be optimized instead of parsing through each descriptor to skip through config descriptors using wTotalLength field. And again, some checks can be done for descriptor types and/or sizes. Just my 2 cents. -TJ --- hw/usb.h.orig 2010-06-23 22:55:27.649182672 -0400 +++ hw/usb.h 2010-06-23 22:56:09.937910171 -0400 @@ -117,6 +117,8 @@ #define USB_DT_INTERFACE 0x04 #define USB_DT_ENDPOINT 0x05 +#define USB_DT_DEVICE_LEN 18 + #define USB_ENDPOINT_XFER_CONTROL 0 #define USB_ENDPOINT_XFER_ISOC 1 #define USB_ENDPOINT_XFER_BULK 2 --- usb-linux.c.orig 2010-06-23 22:56:23.191339634 -0400 +++ usb-linux.c 2010-06-24 00:08:19.437515669 -0400 @@ -299,6 +299,9 @@ i = 0; dev_descr_len = dev->descr[0]; + if (dev_descr_len == 0x18) + dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy device(s) reporting len in hex */ + if (dev_descr_len > dev->descr_len) { goto fail; }