qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 9e3b9f: rtl8139: Fix behaviour for old kernel


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 9e3b9f: rtl8139: Fix behaviour for old kernels.
Date: Thu, 01 Aug 2024 22:54:53 -0700

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: 9e3b9f27658cce308b7f71b19a4ec31749575414
      
https://github.com/qemu/qemu/commit/9e3b9f27658cce308b7f71b19a4ec31749575414
  Author: Hans <sungdgdhtryrt@gmail.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M hw/net/rtl8139.c

  Log Message:
  -----------
  rtl8139: Fix behaviour for old kernels.

Old linux kernel rtl8139 drivers (ex. debian 2.1) uses outb to set the rx
mode for RxConfig. Unfortunatelly qemu does not support outb for RxConfig.

Signed-off-by: Hans <sungdgdhtryrt@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: f1595ceb9aad36a6c1da95bcb77ab9509b38822d
      
https://github.com/qemu/qemu/commit/f1595ceb9aad36a6c1da95bcb77ab9509b38822d
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M hw/net/virtio-net.c

  Log Message:
  -----------
  virtio-net: Ensure queue index fits with RSS

Ensure the queue index points to a valid queue when software RSS
enabled. The new calculation matches with the behavior of Linux's TAP
device with the RSS eBPF program.

Fixes: 4474e37a5b3a ("virtio-net: implement RX RSS processing")
Reported-by: Zhibin Hu <huzhibin5@huawei.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: f937309fbdbb48c354220a3e7110c202ae4aa7fa
      
https://github.com/qemu/qemu/commit/f937309fbdbb48c354220a3e7110c202ae4aa7fa
  Author: thomas <east.moutain.yang@gmail.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M hw/net/virtio-net.c
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h

  Log Message:
  -----------
  virtio-net: Fix network stall at the host side waiting for kick

Patch 06b12970174 ("virtio-net: fix network stall under load")
added double-check to test whether the available buffer size
can satisfy the request or not, in case the guest has added
some buffers to the avail ring simultaneously after the first
check. It will be lucky if the available buffer size becomes
okay after the double-check, then the host can send the packet
to the guest. If the buffer size still can't satisfy the request,
even if the guest has added some buffers, viritio-net would
stall at the host side forever.

The patch enables notification and checks whether the guest has
added some buffers since last check of available buffers when
the available buffers are insufficient. If no buffer is added,
return false, else recheck the available buffers in the loop.
If the available buffers are sufficient, disable notification
and return true.

Changes:
1. Change the return type of virtqueue_get_avail_bytes() from void
   to int, it returns an opaque that represents the shadow_avail_idx
   of the virtqueue on success, else -1 on error.
2. Add a new API: virtio_queue_enable_notification_and_check(),
   it takes an opaque as input arg which is returned from
   virtqueue_get_avail_bytes(). It enables notification firstly,
   then checks whether the guest has added some buffers since
   last check of available buffers or not by virtio_queue_poll(),
   return ture if yes.

The patch also reverts patch "06b12970174".

The case below can reproduce the stall.

                                       Guest 0
                                     +--------+
                                     | iperf  |
                    ---------------> | server |
         Host       |                +--------+
       +--------+   |                    ...
       | iperf  |----
       | client |----                  Guest n
       +--------+   |                +--------+
                    |                | iperf  |
                    ---------------> | server |
                                     +--------+

Boot many guests from qemu with virtio network:
 qemu ... -netdev tap,id=net_x \
    -device virtio-net-pci-non-transitional,\
    iommu_platform=on,mac=xx:xx:xx:xx:xx:xx,netdev=net_x

Each guest acts as iperf server with commands below:
 iperf3 -s -D -i 10 -p 8001
 iperf3 -s -D -i 10 -p 8002

The host as iperf client:
 iperf3 -c guest_IP -p 8001 -i 30 -w 256k -P 20 -t 40000
 iperf3 -c guest_IP -p 8002 -i 30 -w 256k -P 20 -t 40000

After some time, the host loses connection to the guest,
the guest can send packet to the host, but can't receive
packet from the host.

It's more likely to happen if SWIOTLB is enabled in the guest,
allocating and freeing bounce buffer takes some CPU ticks,
copying from/to bounce buffer takes more CPU ticks, compared
with that there is no bounce buffer in the guest.
Once the rate of producing packets from the host approximates
the rate of receiveing packets in the guest, the guest would
loop in NAPI.

         receive packets    ---
               |             |
               v             |
           free buf      virtnet_poll
               |             |
               v             |
     add buf to avail ring  ---
               |
               |  need kick the host?
               |  NAPI continues
               v
         receive packets    ---
               |             |
               v             |
           free buf      virtnet_poll
               |             |
               v             |
     add buf to avail ring  ---
               |
               v
              ...           ...

On the other hand, the host fetches free buf from avail
ring, if the buf in the avail ring is not enough, the
host notifies the guest the event by writing the avail
idx read from avail ring to the event idx of used ring,
then the host goes to sleep, waiting for the kick signal
from the guest.

Once the guest finds the host is waiting for kick singal
(in virtqueue_kick_prepare_split()), it kicks the host.

The host may stall forever at the sequences below:

         Host                        Guest
     ------------                 -----------
 fetch buf, send packet           receive packet ---
         ...                          ...         |
 fetch buf, send packet             add buf       |
         ...                        add buf   virtnet_poll
    buf not enough      avail idx-> add buf       |
    read avail idx                  add buf       |
                                    add buf      ---
                                  receive packet ---
    write event idx                   ...         |
    wait for kick                   add buf   virtnet_poll
                                      ...         |
                                                 ---
                                 no more packet, exit NAPI

In the first loop of NAPI above, indicated in the range of
virtnet_poll above, the host is sending packets while the
guest is receiving packets and adding buffers.
 step 1: The buf is not enough, for example, a big packet
         needs 5 buf, but the available buf count is 3.
         The host read current avail idx.
 step 2: The guest adds some buf, then checks whether the
         host is waiting for kick signal, not at this time.
         The used ring is not empty, the guest continues
         the second loop of NAPI.
 step 3: The host writes the avail idx read from avail
         ring to used ring as event idx via
         virtio_queue_set_notification(q->rx_vq, 1).
 step 4: At the end of the second loop of NAPI, recheck
         whether kick is needed, as the event idx in the
         used ring written by the host is beyound the
         range of kick condition, the guest will not
         send kick signal to the host.

Fixes: 06b12970174 ("virtio-net: fix network stall under load")
Cc: qemu-stable@nongnu.org
Signed-off-by: Wencheng Yang <east.moutain.yang@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: bb1326abd9df64692d5c4f6dadf0719a2f1d1c2d
      
https://github.com/qemu/qemu/commit/bb1326abd9df64692d5c4f6dadf0719a2f1d1c2d
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M qemu-options.hx

  Log Message:
  -----------
  net: update netdev stream/dgram man page

Add the description of "-netdev stream" and "-netdev dgram" in the QEMU
manpage.

Add some examples on how to use them.

Fixes: 5166fe0ae46d ("qapi: net: add stream and dgram netdevs")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 178413a1031af79f1a224e021e3dfd422e3787df
      
https://github.com/qemu/qemu/commit/178413a1031af79f1a224e021e3dfd422e3787df
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M qemu-options.hx

  Log Message:
  -----------
  net: update netdev stream man page with unix socket

Add the description of "-netdev stream" with a unix domain socket.
The code has been added but the man page has not been updated.

Include an example how to use "-netdev stream" and "passt" in place
of "-netdev user".
("passt" is a non privileged translation proxy between layer-2, like
"-netdev stream", and layer-4 on host, like TCP, UDP, ICMP/ICMPv6 echo)

Fixes: 13c6be96618c ("net: stream: add unix socket")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 8e67680dcb24b5353b936b514f14949cc1935738
      
https://github.com/qemu/qemu/commit/8e67680dcb24b5353b936b514f14949cc1935738
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M qemu-options.hx

  Log Message:
  -----------
  net: update netdev dgram man page with unix socket

Add the description of "-netdev dgram" with a unix domain socket.
The code has been added but the man page has not been updated.

Fixes: 784e7a253104 ("net: dgram: add unix socket")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: f6a3158c825cc8265e1596cb9b2d0ea2f09d3a4e
      
https://github.com/qemu/qemu/commit/f6a3158c825cc8265e1596cb9b2d0ea2f09d3a4e
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M qemu-options.hx

  Log Message:
  -----------
  net: update netdev stream man page with the reconnect parameter

"-netdev stream" supports a reconnect parameter that attempts to
reconnect automatically the socket if it is disconnected. The code
has been added but the man page has not been updated.

Fixes: 148fbf0d58a6 ("net: stream: add a new option to automatically reconnect"
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: 64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca
      
https://github.com/qemu/qemu/commit/64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca
  Author: David Woodhouse <dwmw@amazon.co.uk>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M net/net.c

  Log Message:
  -----------
  net: Reinstate '-net nic, model=help' output as documented in man page

While refactoring the NIC initialization code, I broke '-net nic,model=help'
which no longer outputs a list of available NIC models.

Fixes: 2cdeca04adab ("net: report list of available models according to 
platform")
Cc: qemu-stable@nongnu.org
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Jason Wang <jasowang@redhat.com>


  Commit: c4d242501a61093a8b80ee8f6dd071c5110a100c
      
https://github.com/qemu/qemu/commit/c4d242501a61093a8b80ee8f6dd071c5110a100c
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-08-02 (Fri, 02 Aug 2024)

  Changed paths:
    M hw/net/rtl8139.c
    M hw/net/virtio-net.c
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h
    M net/net.c
    M qemu-options.hx

  Log Message:
  -----------
  Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into staging

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCAAdFiEEIV1G9IJGaJ7HfzVi7wSWWzmNYhEFAmasTgwACgkQ7wSWWzmN
# YhFUtAgAq45v7fQJ7cKKwRam/VrIkxT5cM59ODwzLSL9kPWfL6f/bJ7xM/zvLyvn
# LNBXFWWu+eNKA73f95cckZwaqZ4U6giGbiesCACn1IpgVtieLS+Lq78jsifKIAsR
# yxFvbT9oLhU0dZ1Up3+isc6V+jeAE4ZYu4KOiIt7PscTEzkJl+vSUjN4X9rRVtUD
# PzONUacL6MoTJtX8UZJZXNzLN9JTsN39Gx+LSDGQ27MDmDvE3R9BW+T0ZgF9JQZ7
# wnrL5sharqF3gxa7X55fPBI1qwY5gWcH0yyJpRdM8guA13vhtvlrhNSypip9eKWi
# HtPHUTKEB5YOvF236WRiuQPIm/GNpA==
# =7HGN
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 02 Aug 2024 01:10:04 PM AEST
# gpg:                using RSA key 215D46F48246689EC77F3562EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) 
<jasowang@redhat.com>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F  3562 EF04 965B 398D 6211

* tag 'net-pull-request' of https://github.com/jasowang/qemu:
  net: Reinstate '-net nic, model=help' output as documented in man page
  net: update netdev stream man page with the reconnect parameter
  net: update netdev dgram man page with unix socket
  net: update netdev stream man page with unix socket
  net: update netdev stream/dgram man page
  virtio-net: Fix network stall at the host side waiting for kick
  virtio-net: Ensure queue index fits with RSS
  rtl8139: Fix behaviour for old kernels.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/31669121a01a...c4d242501a61

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications



reply via email to

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