qemu-commits
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]