[Qemu-devel] Re: ehci update

[David S. Ahern]

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. :-)

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

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.

David

> 
> Jan
>