Re: [Qemu-devel] Re: ehci update

[Alexander Graf]

On 14.04.2010, at 01:50, 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. :-)
> 
>> 
>>> 
>>> 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.

Any reason we're not using libusb?


Alex