On 27.08.2025 00:52, Fabiano Rosas wrote:
Michael Tokarev <m...@tls.msk.ru> writes:
+CC Akihiko
Hi!
This is
commit c0b32426ce56182c1ce2a12904f3a702c2ecc460
Author: Marco Cavenati <marco.caven...@eurecom.fr>
Date: Wed Mar 26 17:22:30 2025 +0100
migration: fix SEEK_CUR offset calculation in qio_channel_block_seek
which went to 10.0.0-rc2, and has been cherry-picked to
7.2 and 9.2 stable series.
Reportedly it breaks migration in 7.2.18 and up. Which is
kinda strange, as it shouldn't do any harm?
Yeah, this is not it. Unless you're using colo or mapped-ram.
https://bugs.debian.org/1112044
any guess what's going on?
The virtio changes are probably the issue. One of them touches
mhdr.num_buffers, under mergeable_rx_bufs, which is migrated state. The
flag in turn depends on VIRTIO_NET_F_MRG_RXBUF, which is set on the
cmdline with -device virtio-net-pci,mrg_rxbuf= but also reset by
virtio_set_features_nocheck, if I'm reading this right.
Let's ask Akihiko.
The reporter just reported that they used the wrong commit id, --
actually, the issue is caused by ce1431615292dc735597db4062834b:
commit ce1431615292dc735597db4062834bfb271381bc
Author: Akihiko Odaki <od...@rsg.ci.i.u-tokyo.ac.jp>
Date: Mon Apr 21 21:17:20 2025 +0900
virtio: Call set_features during reset
virtio-net expects set_features() will be called when the feature set
used by the guest changes to update the number of virtqueues but it is
not called during reset, which will clear all features, leaving the
queues added for VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS. Not only these
extra queues are visible to the guest, they will cause segmentation
fault during migration.
Call set_features() during reset to remove those queues for virtio-net
as we call set_status(). It will also prevent similar bugs for
virtio-net and other devices in the future.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest
doesn't support multiqueue")
Buglink: https://issues.redhat.com/browse/RHEL-73842
Cc: qemu-sta...@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20250421-reset-v2-1-e4c1ead88...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit 0caed25cd171c611781589b5402161d27d57229c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
(so commit 0caed25cd171c611781589b5402161 in master).
So yes, this one looks much more real in this context.
Thanks,
/mjt
