From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O28ZP-0002xa-5e for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:48:19 -0400 Received: from [140.186.70.92] (port=58537 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O28ZN-0002vl-1a for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:48:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O28ZK-0006Si-U0 for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:48:16 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:48251) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O28ZK-0006SX-I7 for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:48:14 -0400 Message-ID: <4BC61BFC.1070701@web.de> Date: Wed, 14 Apr 2010 21:48:12 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BC3F3FC.6050809@cisco.com> <4BC4FFC8.3060702@web.de> <4BC50337.8040201@cisco.com> In-Reply-To: <4BC50337.8040201@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEFA4D61036DCCDF196016366" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: ehci update List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEFA4D61036DCCDF196016366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David S. Ahern wrote: >=20 > On 04/13/2010 05:35 PM, Jan Kiszka wrote: >> David S. Ahern wrote: >>> After a month of code refactoring and clean ups, etc, I thought I wou= ld >>> send along an update. The attached patch is relative to your ehci >>> branch; I also attached the full usb-ehci.c file for easier reading. >> Thanks for your work! I applied it and once again merged git head at >> this chance. >> >> Just one request for the future: Please keep a queue of incremental >> changes. This EHCI beast is sufficiently tricky, and at some point >> someone (you included) may want to go back in history to find >> out where some change came from, and why it was applied. >=20 > Agreed. I will submit focused changes from now on. >=20 >> E.g.: We apparently regressed further /wrt my favorite test case (as >> it's self-contained): "-usbdevice net". qemu is now entering an infini= te >> loop when you start dhcpcd in the guest on that interface. >=20 > I've been focused on a single path -- async, bulk transfers to a USB > key. I take a look at the ethernet device as well. >=20 > I've struggled with the infinite loop part: the async train jumps the > track with FC-12 guest rather quickly (ie., the link list is no longer = a > loop). I put in a loop detector in the advance_state function which > helps for storage devices - but clearly something is not right. I've > been roaming the ehci_hcd code in the kernel as well looking for clues.= > A lot of details to gel and the day job keeps getting in the way. :-) Yeah, I can imagine. Would love to hack on this as well, but then I look at my backlog... ;) >=20 >>> At this point I can get a Windows XP guest to format a 4GB key and re= ad >>> from and write to it. I can get an FC-12 guest to format a 4GB key an= d >>> an 8GB key as well as read from and write to both. Write rates are on= >>> the order of 8 MB/sec for dd: >>> >>> # dd if=3D/dev/zero of=3Dtest bs=3D1M count=3D100 oflag=3Ddsync >>> 100+0 records in >>> 100+0 records out >>> 104857600 bytes (105 MB) copied, 12.1205 s, 8.7 MB/s >>> >>> rsync of text files (e.g., /var/log) is on the order of 2MB/sec. >>> >>> 4GB keys are definitely more stable; the 8GB is not recognized by >>> Windows XP. >>> >>> It still needs a lot of love, but definitely an improvement from the >>> last version. The biggest difference for the performance boost and >>> stability is discovering that the usbfs in linux limits transactions = to >>> 16k versus the EHCI spec which allows 20k per qTD. I added a hack to >>> submit which detects 20k requests from a guest and breaks it up into = 2 >>> requests through the host (a 16k and then a 4k). >> Did someone already bring this up on LKML or wherever usbfs is >> discussed? Should be fixable, I naively guess. >=20 > I submitted the patch to linux-usb and it was nack'ed. The response was= > that memory is allocated in powers of 2 so trying to up the limit from > 16k to 20k means it will actually want to find 32k of contiguous memory= =2E > The suggestion was to handle it with multiple requests within qemu. I > guess libusb does that. [ Ah, now I actually read this part. ] Hmm, unfortunate. We can just hope it does not hurt performance too much (compared to all the overhead emulation brings, it should not). >=20 > Right now there is a hack in the ehci model to do this, but the > usb-linux code would be a better place since it might be specific to > linux hosts. If libusb can handle this efficiently, that is surely be the best way. But maybe usb-linux looks different for some subtle reason... Jan --------------enigEFA4D61036DCCDF196016366 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvGG/wACgkQitSsb3rl5xQ7RQCg2DqYeARKN0WDrWqmTPcC4Fub KRkAoOvCWStuBfeDYLsjf4pHI1jdLGR8 =JShu -----END PGP SIGNATURE----- --------------enigEFA4D61036DCCDF196016366--