[Qemu-devel] Re: ehci update

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3603 bytes --]

David S. Ahern wrote:
> 
> 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 would
>>> 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.
> 
> Agreed. I will submit focused changes from now on.
> 
>> E.g.: We apparently regressed further /wrt my favorite test case (as
>> it's self-contained): "-usbdevice net". qemu is now entering an infinite
>> loop when you start dhcpcd in the guest on that interface.
> 
> 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.
> 
> 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... ;)

> 
>>> At this point I can get a Windows XP guest to format a 4GB key and read
>>> from and write to it. I can get an FC-12 guest to format a 4GB key and
>>> 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=/dev/zero of=test bs=1M count=100 oflag=dsync
>>> 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.
> 
> 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.
> 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).

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]