Re: [Qemu-devel] [PATCH 4/5] uhci: rewrite UHCI emulator, fully async operation with multiple outstanding transactions

[Juergen Lock]

In article <address@hidden> you write:
>This is esentially a re-write of the QEMU UHCI layer. My initial goal
>was to support fully async operation with multiple outstanding async
>transactions. Along the way I realized that I can greatly simplify
>and cleanup the overall logic. There was a lot of duplicate and confusing
>code in the UHCI data structure parsing and other places.
>We were actually violating UHCI spec in handling async ISOC transaction
>(host controller is not supposed to write into the frame pointer).
>
>The reason I wanted to support fully async operation is because current
>synchronous version is unusable with most devices exported from host
>(via usb-linux.c). Transactions take a long time and the whole VM becomes
>slow as hell.
>
>Current async support is very rudimentory and for the most part
>non-functional. Single transaction at a time is simply not enough. I have
>a device for which XP driver submits both IN and OUT packets at the same
>time. IN packet always times out unless OUT packet makes it to the device.
>Hence we must be able to process both in order for that device to work.
>
>The new code is backwards compatible and was first tested agains original
>synchronous usb-linux.c and builtin usb devices like tablet which is also
>synchronous. Rewrite of the usb-linux.c is coming up next.
>
>Async support was tested against various XP versions (ie XP, SP2, SP3) and
>a bunch of different USB devices: serial port controllers, mice, keyboard,
>JTAG dongles (from Xilinx and Altera).
>
>ISOC support was only lighly tested and needs more work. It's not any worse
>than current code though.
>
>UHCI parser changes are probably somewhat hard to review without the
>understanding of the UHCI spec.
>The async design should be fairly easy to follow. Basically we have a list
>of async objects for each pending transfer. Async objects are tagged with
>the original TD (transfer descriptor) address and token. We now support
>unlimited number of outstanding isoc and one outstanding bulk/intr/ctrl
>transfer per QH (queue head). UHCI spec does not have a clear protocol for
>the cancelation of the trasfer requests. Driver can yank out TDs on any
>frame boundary. In oder to handle that I added somewhat fancy TD validation
>logic logic to avoid unnecessary cancelations.
>
>Signed-off-by: Max Krasnyansky <address@hidden>
>---

This is whats got committed as r5050, right?  It causes a large slowdown
with some linux guests, as posted here:
        http://lists.gnu.org/archive/html/qemu-devel/2008-09/msg01201.html
As mentioned the guest I tested was:
        sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso
It uses a Linux 2.6.26 kernel, a FreeBSD guest is not affected by the
slowness, could this be related to dynticks?

 Oh and on one box transfers over the emulated usb nic even sometimes
stall, I have to ping the guest's ip for them to continue, and the ping
then loses packets too.

 Thanx, :)
        Juergen