summaryrefslogtreecommitdiff
path: root/qom
diff options
context:
space:
mode:
authorStefan Hajnoczi <stefanha@redhat.com>2013-05-22 14:50:18 +0200
committerMichael Roth <mdroth@linux.vnet.ibm.com>2013-06-11 16:46:51 -0500
commit749806d1a741d23181e5c8f807c411868384b122 (patch)
tree1cc1fdf2139044fde8482c67a1e96806aae0a78e /qom
parenta6fc2cd986e62fc019daf284ee356a4050a44529 (diff)
downloadqemu-749806d1a741d23181e5c8f807c411868384b122.tar.gz
qemu-749806d1a741d23181e5c8f807c411868384b122.tar.bz2
qemu-749806d1a741d23181e5c8f807c411868384b122.zip
rtl8139: flush queued packets when RxBufPtr is written
Net queues support efficient "receive disable". For example, tap's file descriptor will not be polled while its peer has receive disabled. This saves CPU cycles for needlessly copying and then dropping packets which the peer cannot receive. rtl8139 is missing the qemu_flush_queued_packets() call that wakes the queue up when receive becomes possible again. As a result, the Windows 7 guest driver reaches a state where the rtl8139 cannot receive packets. The driver has actually refilled the receive buffer but we never resume reception. The bug can be reproduced by running a large FTP 'get' inside a Windows 7 guest: $ qemu -netdev tap,id=tap0,... -device rtl8139,netdev=tap0 The Linux guest driver does not trigger the bug, probably due to a different buffer management strategy. Reported-by: Oliver Francke <oliver.francke@filoo.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 00b7ade807b5ce6779ddd86ce29c5521ec5c529a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Diffstat (limited to 'qom')
0 files changed, 0 insertions, 0 deletions