[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 94b529: virtio_net: flush uncompleted TX on r
From: |
GitHub |
Subject: |
[Qemu-commits] [qemu/qemu] 94b529: virtio_net: flush uncompleted TX on reset |
Date: |
Mon, 26 Mar 2018 06:13:56 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 94b52958b77a2a040564cf7ed716d3a9545d94e5
https://github.com/qemu/qemu/commit/94b52958b77a2a040564cf7ed716d3a9545d94e5
Author: Greg Kurz <address@hidden>
Date: 2018-03-26 (Mon, 26 Mar 2018)
Changed paths:
M hw/net/virtio-net.c
M include/net/net.h
M net/net.c
Log Message:
-----------
virtio_net: flush uncompleted TX on reset
If the backend could not transmit a packet right away for some reason,
the packet is queued for asynchronous sending. The corresponding vq
element is tracked in the async_tx.elem field of the VirtIONetQueue,
for later freeing when the transmission is complete.
If a reset happens before completion, virtio_net_tx_complete() will push
async_tx.elem back to the guest anyway, and we end up with the inuse flag
of the vq being equal to -1. The next call to virtqueue_pop() is then
likely to fail with "Virtqueue size exceeded".
This can be reproduced easily by starting a guest with an hubport backend
that is not connected to a functional network, eg,
-device virtio-net-pci,netdev=hub0 -netdev hubport,id=hub0,hubid=0
and no other -netdev hubport,hubid=0 on the command line.
The appropriate fix is to ensure that such an asynchronous transmission
cannot survive a device reset. So for all queues, we first try to send
the packet again, and eventually we purge it if the backend still could
not deliver it.
CC: address@hidden
Reported-by: R. Nageswara Sastry <address@hidden>
Buglink: https://github.com/open-power-host-os/qemu/issues/37
Signed-off-by: Greg Kurz <address@hidden>
Tested-by: R. Nageswara Sastry <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
Commit: 7587855cd23755a7a6bd01b026611465f5584ecd
https://github.com/qemu/qemu/commit/7587855cd23755a7a6bd01b026611465f5584ecd
Author: Julia Suvorova via Qemu-devel <address@hidden>
Date: 2018-03-26 (Mon, 26 Mar 2018)
Changed paths:
M net/vde.c
Log Message:
-----------
net/vde: print error on vde_open() failure
Despite the fact that now when the initialization of vde fails, qemu
does not end silently, no informative error is printed. The patch
generates an error and pushes it through the calling function.
Related bug: https://bugs.launchpad.net/qemu/+bug/676029
Signed-off-by: Julia Suvorova <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
Commit: 2ffd221d07a671f72354a063d3080f244ec80b20
https://github.com/qemu/qemu/commit/2ffd221d07a671f72354a063d3080f244ec80b20
Author: Peter Maydell <address@hidden>
Date: 2018-03-26 (Mon, 26 Mar 2018)
Changed paths:
M hw/net/virtio-net.c
M include/net/net.h
M net/net.c
M net/vde.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
staging
# gpg: Signature made Mon 26 Mar 2018 07:53:27 BST
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <address@hidden>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* remotes/jasowang/tags/net-pull-request:
net/vde: print error on vde_open() failure
virtio_net: flush uncompleted TX on reset
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/7b1db0908d88...2ffd221d07a6
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 94b529: virtio_net: flush uncompleted TX on reset,
GitHub <=