aboutsummaryrefslogtreecommitdiff
path: root/hw/pci.c
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2012-10-24 18:14:04 +0200
committerGerd Hoffmann <kraxel@redhat.com>2012-10-25 09:08:09 +0200
commitb4ea86649915eca5551a5166f76e7a9d9032de50 (patch)
treed5919675b44f6bf14aa8726eab16f0c7c51c205e /hw/pci.c
parente3a36bce1d0123d003855f7731494e6d6f550fcc (diff)
downloadqemu-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