diff options
author | Hans de Goede <hdegoede@redhat.com> | 2012-10-24 18:14:04 +0200 |
---|---|---|
committer | Gerd Hoffmann <kraxel@redhat.com> | 2012-10-25 09:08:09 +0200 |
commit | b4ea86649915eca5551a5166f76e7a9d9032de50 (patch) | |
tree | d5919675b44f6bf14aa8726eab16f0c7c51c205e /hw/pci.c | |
parent | e3a36bce1d0123d003855f7731494e6d6f550fcc (diff) | |
download | qemu-b4ea86649915eca5551a5166f76e7a9d9032de50.zip qemu-b4ea86649915eca5551a5166f76e7a9d9032de50.tar.gz qemu-b4ea86649915eca5551a5166f76e7a9d9032de50.tar.bz2 |
ehci: Retry to fill the queue while waiting for td completion
If the guest is using multiple transfers to try and keep the usb bus busy /
used at maximum efficiency, currently we would see / do the following:
1) submit transfer 1 to the device
2) submit transfer 2 to the device
3) report transfer 1 completion to guest
4) report transfer 2 completion to guest
5) submit transfer 1 to the device
6) report transfer 1 completion to guest
7) submit transfer 2 to the device
8) report transfer 2 completion to guest
etc.
So after the initial submission we would effectively only have 1 transfer
in flight, rather then 2. This is caused by us not checking the queue for
addition of new transfers by the guest (ie the resubmission of a recently
finished transfer), while waiting for a pending transfer to complete.
This patch does add a check for this, changing the sequence to:
1) submit transfer 1 to the device
2) submit transfer 2 to the device
3) report transfer 1 completion to guest
4) submit transfer 1 to the device
5) report transfer 2 completion to guest
6) submit transfer 2 to the device
etc.
Thus keeping 2 transfers in flight (most of the time, and always 1),
as intended by the guest.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Diffstat (limited to 'hw/pci.c')
0 files changed, 0 insertions, 0 deletions