qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 12e488: virtio-net: Fix vhost virtqueue notif


From: Manos Pitsidianakis
Subject: [Qemu-commits] [qemu/qemu] 12e488: virtio-net: Fix vhost virtqueue notifiers for RSS
Date: Tue, 09 Apr 2024 22:40:44 -0700

  Branch: refs/heads/staging-8.2
  Home:   https://github.com/qemu/qemu
  Commit: 12e4886108358b36050acc243b17a0a5e07c184e
      
https://github.com/qemu/qemu/commit/12e4886108358b36050acc243b17a0a5e07c184e
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2024-03-31 (Sun, 31 Mar 2024)

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

  Log Message:
  -----------
  virtio-net: Fix vhost virtqueue notifiers for RSS

virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask()
checked VIRTIO_NET_F_MQ to know there are multiple queues, but
VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue,
which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is
enabled.

Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for 
vhost_vdpa")
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1c188fc8cbffc5f05cc616cab4e1372fb6e6f11f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: d3e9e0fb29d35bb1a97cf348a99d82b29bae5d86
      
https://github.com/qemu/qemu/commit/d3e9e0fb29d35bb1a97cf348a99d82b29bae5d86
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2024-03-31 (Sun, 31 Mar 2024)

  Changed paths:
    M hw/net/net_tx_pkt.c

  Log Message:
  -----------
  hw/net/net_tx_pkt: Fix virtio header without checksum offloading

It is incorrect to have the VIRTIO_NET_HDR_F_NEEDS_CSUM set when
checksum offloading is disabled so clear the bit.

TCP/UDP checksum is usually offloaded when the peer requires virtio
headers because they can instruct the peer to compute checksum. However,
igb disables TX checksum offloading when a VF is enabled whether the
peer requires virtio headers because a transmitted packet can be routed
to it and it expects the packet has a proper checksum. Therefore, it
is necessary to have a correct virtio header even when checksum
offloading is disabled.

A real TCP/UDP checksum will be computed and saved in the buffer when
checksum offloading is disabled. The virtio specification requires to
set the packet checksum stored in the buffer to the TCP/UDP pseudo
header when the VIRTIO_NET_HDR_F_NEEDS_CSUM bit is set so the bit must
be cleared in that case.

Fixes: ffbd2dbd8e64 ("e1000e: Perform software segmentation for loopback")
Buglink: https://issues.redhat.com/browse/RHEL-23067
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 89a8de364b51db8107d2a210314431885ac52238)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 3cdfd68e4e6586c5c4583fb8cf6cc8074c73b51c
      
https://github.com/qemu/qemu/commit/3cdfd68e4e6586c5c4583fb8cf6cc8074c73b51c
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-03-31 (Sun, 31 Mar 2024)

  Changed paths:
    M tcg/optimize.c
    M tests/tcg/aarch64/Makefile.target
    A tests/tcg/aarch64/test-2248.c

  Log Message:
  -----------
  tcg/optimize: Fix sign_mask for logical right-shift

The 'sign' computation is attempting to locate the sign bit that has
been repeated, so that we can test if that bit is known zero.  That
computation can be zero if there are no known sign repetitions.

Cc: qemu-stable@nongnu.org
Fixes: 93a967fbb57 ("tcg/optimize: Propagate sign info for shifting")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2248
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 2911e9b95f3bb03783ae5ca3e2494dc3b44a9161)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 35fface50fe56ea4a4d236d11e6f07bd6e153366
      
https://github.com/qemu/qemu/commit/35fface50fe56ea4a4d236d11e6f07bd6e153366
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-04-01 (Mon, 01 Apr 2024)

  Changed paths:
    M target/hppa/translate.c

  Log Message:
  -----------
  target/hppa: Clear psw_n for BE on use_nullify_skip path

Along this path we have already skipped the insn to be
nullified, so the subsequent insn should be executed.

Cc: qemu-stable@nongnu.org
Reported-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 4a3aa11e1fb25c28c24a43fd2835c429b00a463d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 31684769650a2bd57ac2c1fc9441f08d4f9b4e1f
      
https://github.com/qemu/qemu/commit/31684769650a2bd57ac2c1fc9441f08d4f9b4e1f
  Author: Avihai Horon <avihaih@nvidia.com>
  Date:   2024-04-01 (Mon, 01 Apr 2024)

  Changed paths:
    M migration/migration.c

  Log Message:
  -----------
  migration/postcopy: Ensure postcopy_start() sets errp if it fails

There are several places where postcopy_start() fails without setting
errp. This can cause a null pointer de-reference, as in case of error,
the caller of postcopy_start() copies/prints the error set in errp.

Fix it by setting errp in all of postcopy_start() error paths.

Cc: qemu-stable <qemu-stable@nongnu.org>
Fixes: 908927db28ea ("migration: Update error description whenever migration 
fails")
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/r/20240328140252.16756-3-avihaih@nvidia.com
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit d0ad271a7613459bd0a3397c8071a4ad06f3f7eb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 2befb8a9c7b76488be1c2535f39f9105276f25fa
      
https://github.com/qemu/qemu/commit/2befb8a9c7b76488be1c2535f39f9105276f25fa
  Author: Michael Tokarev <mjt@tls.msk.ru>
  Date:   2024-04-01 (Mon, 01 Apr 2024)

  Changed paths:
    M .gitlab-ci.d/cirrus.yml

  Log Message:
  -----------
  gitlab-ci/cirrus: switch from 'master' to 'latest'

Commit ab72522797 "gitlab: switch from 'stable' to
'latest' docker container tags" switched most tags
to 'latest' but missed cirrus image.  Fix this now.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2256
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 20240401051633.2780456-1-mjt@tls.msk.ru
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 1d2f2b35bc86b7a13dc3009a3c5031220aa0b7de)


  Commit: 2702763548950689b4eccb0e040b56948da8bf4f
      
https://github.com/qemu/qemu/commit/2702763548950689b4eccb0e040b56948da8bf4f
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-04-02 (Tue, 02 Apr 2024)

  Changed paths:
    M hw/intc/arm_gicv3_cpuif.c

  Log Message:
  -----------
  hw/intc/arm_gicv3: ICC_HPPIR* return SPURIOUS if int group is disabled

If the group of the highest priority pending interrupt is disabled
via ICC_IGRPEN*, the ICC_HPPIR* registers should return
INTID_SPURIOUS, not the interrupt ID.  (See the GIC architecture
specification pseudocode functions ICC_HPPIR1_EL1[] and
HighestPriorityPendingInterrupt().)

Make HPPIR reads honour the group disable, the way we already do
when determining whether to preempt in icc_hppi_can_preempt().

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240328153333.2522667-1-peter.maydell@linaro.org
(cherry picked from commit 44e25fbc1900c99c91a44e532c5bd680bc403459)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: e961fa43e94bf83e2dd4a2ed132c1c40455afdc3
      
https://github.com/qemu/qemu/commit/e961fa43e94bf83e2dd4a2ed132c1c40455afdc3
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-04-02 (Tue, 02 Apr 2024)

  Changed paths:
    M target/arm/tcg/translate.c

  Log Message:
  -----------
  target/arm: take HSTR traps of cp15 accesses to EL2, not EL1

The HSTR_EL2 register allows the hypervisor to trap AArch32 EL1 and
EL0 accesses to cp15 registers.  We incorrectly implemented this so
they trap to EL1 when we detect the need for a HSTR trap at code
generation time.  (The check in access_check_cp_reg() which we do at
runtime to catch traps from EL0 is correctly routing them to EL2.)

Use the correct target EL when generating the code to take the trap.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2226
Fixes: 049edada5e93df ("target/arm: Make HSTR_EL2 traps take priority over 
UNDEF-at-EL1")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240325133116.2075362-1-peter.maydell@linaro.org
(cherry picked from commit fbe5ac5671a9cfcc7f4aee9a5fac7720eea08876)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 9c2b8194aceb634e414325c4fa79adcaddc55210
      
https://github.com/qemu/qemu/commit/9c2b8194aceb634e414325c4fa79adcaddc55210
  Author: Yajun Wu <yajunw@nvidia.com>
  Date:   2024-04-03 (Wed, 03 Apr 2024)

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

  Log Message:
  -----------
  hw/net/virtio-net: fix qemu set used ring flag even vhost started

When vhost-user or vhost-kernel is handling virtio net datapath,
QEMU should not touch used ring.

But with vhost-user socket reconnect scenario, in a very rare case
(has pending kick event). VRING_USED_F_NO_NOTIFY is set by QEMU in
following code path:

        #0  virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0) 
at ../hw/virtio/virtio.c:511
        #1  0x0000559d6dbf033b in virtio_queue_set_notification 
(vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576
        #2  0x0000559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0, 
vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801
        #3  0x0000559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at 
../hw/virtio/virtio.c:2248
        #4  0x0000559d6dbf79da in virtio_queue_host_notifier_read 
(n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525
        #5  0x0000559d6d9a5814 in virtio_bus_cleanup_host_notifier 
(bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321
        #6  0x0000559d6dbf83c9 in virtio_device_stop_ioeventfd_impl 
(vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774
        #7  0x0000559d6d9a55c8 in virtio_bus_stop_ioeventfd 
(bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259
        #8  0x0000559d6d9a53e8 in virtio_bus_grab_ioeventfd 
(bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199
        #9  0x0000559d6dbf841c in virtio_device_grab_ioeventfd 
(vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783
        #10 0x0000559d6d9bde18 in vhost_dev_enable_notifiers 
(hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592
        #11 0x0000559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70, 
dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266
        #12 0x0000559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0, 
ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412
        #13 0x0000559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0, 
status=15 '\017') at ../hw/net/virtio-net.c:311
        #14 0x0000559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0, 
status=15 '\017') at ../hw/net/virtio-net.c:392
        #15 0x0000559d6dbb60d8 in virtio_net_set_link_status 
(nc=0x559d7048d890) at ../hw/net/virtio-net.c:455
        #16 0x0000559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1", 
up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459
        #17 0x0000559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0, 
event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301
        #18 0x0000559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0, 
event=CHR_EVENT_OPENED) at ../chardev/char.c:62
        #19 0x0000559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0, 
event=CHR_EVENT_OPENED) at ../chardev/char.c:82

This issue causes guest kernel stop kicking device and traffic stop.

Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong
VRING_USED_F_NO_NOTIFY set.

Signed-off-by: Yajun Wu <yajunw@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20240402045109.97729-1-yajunw@nvidia.com>
[PMD: Use unlikely()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 4c54f5bc8e1d38f15cc35b6a6932d8fbe219c692)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 46f03be3edabfb7a9fdb0c0a8fa83936a2ee14f7
      
https://github.com/qemu/qemu/commit/46f03be3edabfb7a9fdb0c0a8fa83936a2ee14f7
  Author: Zheyu Ma <zheyuma97@gmail.com>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M hw/block/virtio-blk.c

  Log Message:
  -----------
  block/virtio-blk: Fix memory leak from virtio_blk_zone_report

This modification ensures that in scenarios where the buffer size is
insufficient for a zone report, the function will now properly set an
error status and proceed to a cleanup label, instead of merely
returning.

The following ASAN log reveals it:

==1767400==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 312 byte(s) in 1 object(s) allocated from:
    #0 0x64ac7b3280cd in malloc 
llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
    #1 0x735b02fb9738 in g_malloc 
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
    #2 0x64ac7d23be96 in virtqueue_split_pop hw/virtio/virtio.c:1612:12
    #3 0x64ac7d23728a in virtqueue_pop hw/virtio/virtio.c:1783:16
    #4 0x64ac7cfcaacd in virtio_blk_get_request hw/block/virtio-blk.c:228:27
    #5 0x64ac7cfca7c7 in virtio_blk_handle_vq hw/block/virtio-blk.c:1123:23
    #6 0x64ac7cfecb95 in virtio_blk_handle_output hw/block/virtio-blk.c:1157:5

Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Message-id: 20240404120040.1951466-1-zheyuma97@gmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit bbdf9023665f409113cb07b463732861af63fb47)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6983d1657dc1784288eb299f5f001fb56af705d8
      
https://github.com/qemu/qemu/commit/6983d1657dc1784288eb299f5f001fb56af705d8
  Author: Wei Wang <wei.w.wang@intel.com>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M migration/savevm.c

  Log Message:
  -----------
  migration/postcopy: ensure preempt channel is ready before loading states

Before loading the guest states, ensure that the preempt channel has been
ready to use, as some of the states (e.g. via virtio_load) might trigger
page faults that will be handled through the preempt channel. So yield to
the main thread in the case that the channel create event hasn't been
dispatched.

Cc: qemu-stable <qemu-stable@nongnu.org>
Fixes: 9358982744 ("migration: Send requested page directly in rp-return 
thread")
Originally-by: Lei Wang <lei4.wang@intel.com>
Link: 
https://lore.kernel.org/all/9aa5d1be-7801-40dd-83fd-f7e041ced249@intel.com/T/
Signed-off-by: Lei Wang <lei4.wang@intel.com>
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Link: https://lore.kernel.org/r/20240405034056.23933-1-wei.w.wang@intel.com
[peterx: add a todo section, add Fixes and copy stable for 8.0+]
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 7afbdada7effbc2b97281bfbce0c6df351a3cf88)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f7a1ff69baabcda388a61f5b77d79ab1ed995a3a
      
https://github.com/qemu/qemu/commit/f7a1ff69baabcda388a61f5b77d79ab1ed995a3a
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Use correct SecuritySpace for AArch64 AT ops at EL3

When we do an AT address translation operation, the page table walk
is supposed to be performed in the context of the EL we're doing the
walk for, so for instance an AT S1E2R walk is done for EL2.  In the
pseudocode an EL is passed to AArch64.AT(), which calls
SecurityStateAtEL() to find the security state that we should be
doing the walk with.

In ats_write64() we get this wrong, instead using the current
security space always.  This is fine for AT operations performed from
EL1 and EL2, because there the current security state and the
security state for the lower EL are the same.  But for AT operations
performed from EL3, the current security state is always either
Secure or Root, whereas we want to use the security state defined by
SCR_EL3.{NS,NSE} for the walk. This affects not just guests using
FEAT_RME but also ones where EL3 is Secure state and the EL3 code
is trying to do an AT for a NonSecure EL2 or EL1.

Use arm_security_space_below_el3() to get the SecuritySpace to
pass to do_ats_write() for all AT operations except the
AT S1E3* operations.

Cc: qemu-stable@nongnu.org
Fixes: e1ee56ec2383 ("target/arm: Pass security space rather than flag for AT 
instructions")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2250
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240405180232.3570066-1-peter.maydell@linaro.org
(cherry picked from commit 19b254e86a900dc5ee332e3ac0baf9c521301abf)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: b57b102a81f7530644b79695335389e4c44d0dd9
      
https://github.com/qemu/qemu/commit/b57b102a81f7530644b79695335389e4c44d0dd9
  Author: Wafer <wafer@jaguarmicro.com>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  hw/virtio: Fix packed virtqueue flush used_idx

In the event of writing many chains of descriptors, the device must
write just the id of the last buffer in the descriptor chain, skip
forward the number of descriptors in the chain, and then repeat the
operations for the rest of chains.

Current QEMU code writes all the buffer ids consecutively, and then
skips all the buffers altogether. This is a bug, and can be reproduced
with a VirtIONet device with _F_MRG_RXBUB and without
_F_INDIRECT_DESC:

If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature
but not the VIRTIO_RING_F_INDIRECT_DESC feature,
'VirtIONetQueue->rx_vq' will use the merge feature
to store data in multiple 'elems'.
The 'num_buffers' in the virtio header indicates how many elements are merged.
If the value of 'num_buffers' is greater than 1,
all the merged elements will be filled into the descriptor ring.
The 'idx' of the elements should be the value of 'vq->used_idx' plus 'ndescs'.

Fixes: 86044b24e8 ("virtio: basic packed virtqueue support")
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Wafer <wafer@jaguarmicro.com>
Message-Id: <20240407015451.5228-2-wafer@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 2d9a31b3c27311eca1682cb2c076d7a300441960)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: cd461c8445392d02c268d79f7ed68387b440c4b3
      
https://github.com/qemu/qemu/commit/cd461c8445392d02c268d79f7ed68387b440c4b3
  Author: lyx634449800 <yuxue.liu@jaguarmicro.com>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M hw/virtio/vdpa-dev.c

  Log Message:
  -----------
  vdpa-dev: Fix the issue of device status not updating when configuration 
interruption is triggered

The set_config callback function vhost_vdpa_device_get_config in
vdpa-dev does not fetch the current device status from the hardware
device, causing the guest os to not receive the latest device status
information.

The hardware updates the config status of the vdpa device and then
notifies the os. The guest os receives an interrupt notification,
triggering a get_config access in the kernel, which then enters qemu
internally. Ultimately, the vhost_vdpa_device_get_config function of
vdpa-dev is called

One scenario encountered is when the device needs to bring down the
vdpa net device. After modifying the status field of virtio_net_config
in the hardware, it sends an interrupt notification. However, the guest
os always receives the STATUS field as VIRTIO_NET_S_LINK_UP.

Signed-off-by: Yuxue Liu <yuxue.liu@jaguarmicro.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20240408020003.1979-1-yuxue.liu@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 6ae72f609a21cfc56bf655cd4bcded5d07691ce7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 627aa460baf789b44cfd1d1285d6ad038c245959
      
https://github.com/qemu/qemu/commit/627aa460baf789b44cfd1d1285d6ad038c245959
  Author: Zheyu Ma <zheyuma97@gmail.com>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
    M hw/audio/virtio-snd.c

  Log Message:
  -----------
  virtio-snd: Enhance error handling for invalid transfers

This patch improves error handling in virtio_snd_handle_tx_xfer()
and virtio_snd_handle_rx_xfer() in the VirtIO sound driver. Previously,
'goto' statements were used for error paths, leading to unnecessary
processing and potential null pointer dereferences. Now, 'continue' is
used to skip the rest of the current loop iteration for errors such as
message size discrepancies or null streams, reducing crash risks.

ASAN log illustrating the issue addressed:

ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4
    #0 0x57cea39967b8 in qemu_mutex_lock_impl qemu/util/qemu-thread-posix.c:92:5
    #1 0x57cea128c462 in qemu_mutex_lock qemu/include/qemu/thread.h:122:5
    #2 0x57cea128d72f in qemu_lockable_lock qemu/include/qemu/lockable.h:95:5
    #3 0x57cea128c294 in qemu_lockable_auto_lock 
qemu/include/qemu/lockable.h:105:5
    #4 0x57cea1285eb2 in virtio_snd_handle_rx_xfer 
qemu/hw/audio/virtio-snd.c:1026:9
    #5 0x57cea2caebbc in virtio_queue_notify_vq qemu/hw/virtio/virtio.c:2268:9
    #6 0x57cea2cae412 in virtio_queue_host_notifier_read 
qemu/hw/virtio/virtio.c:3671:9
    #7 0x57cea39822f1 in aio_dispatch_handler qemu/util/aio-posix.c:372:9
    #8 0x57cea3979385 in aio_dispatch_handlers qemu/util/aio-posix.c:414:20
    #9 0x57cea3978eb1 in aio_dispatch qemu/util/aio-posix.c:424:5
    #10 0x57cea3a1eede in aio_ctx_dispatch qemu/util/async.c:360:5

Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-Id: <20240322110827.568412-1-zheyuma97@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a45f09935c88ae352a5ec120418a8b2b36ec1daa)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 20cd0c86553e14c495451ce7d1e2e4efd81041f0
      
https://github.com/qemu/qemu/commit/20cd0c86553e14c495451ce7d1e2e4efd81041f0
  Author: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
  Date:   2024-04-09 (Tue, 09 Apr 2024)

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

  Log Message:
  -----------
  virtio-snd: rewrite invalid tx/rx message handling

The current handling of invalid virtqueue elements inside the TX/RX virt
queue handlers is wrong.

They are added in a per-stream invalid queue to be processed after the
handler is done examining each message, but the invalid message might
not be specifying any stream_id; which means it's invalid to add it to
any stream->invalid queue since stream could be NULL at this point.

This commit moves the invalid queue to the VirtIOSound struct which
guarantees there will always be a valid temporary place to store them
inside the tx/rx handlers. The queue will be emptied before the handler
returns, so the queue must be empty at any other point of the device's
lifetime.

Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-Id: 
<virtio-snd-rewrite-invalid-tx-rx-message-handling-v1.manos.pitsidianakis@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 731655f87f319fd06f27282c6cafbc2467ac8045)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/1e4ec0958ec7...20cd0c86553e

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]