On Tue, Aug 26, 2025 at 11:32:20PM +0300, Michael Tokarev wrote:
> 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?
>
> https://bugs.debian.org/1112044
>
> any guess what's going on?
The only thing I can think of is, when it used to save to some file /
snapshot, then if the old image was stored with some wrong offsets (due to
wrong seek()s) then a new QEMU with correct offsets will instead read wrong
data even if they started to do the right things..
The reporter says:
This occurs during live-migrating a guest onto a host with u15,
migrating it back fixes the softlocks. A reset is required to fix
it but is only required when the receiving host is on the latest
version.
So it's a host-to-host live migration. Is that using TCP as URI? The
problem is I don't even think TCP layer should use io_seek at all.
qio_channel_io_seek() is only used in below (except VFIO when used with
multifd, that doesn't look like what the reporter was using..):
*** migration/file.c:
file_start_outgoing_migration[121] if (offset && qio_channel_io_seek(ioc,
offset, SEEK_SET, errp) < 0) {
file_start_incoming_migration[190] qio_channel_io_seek(QIO_CHANNEL(fioc),
offset, SEEK_SET, errp) < 0) {
*** migration/qemu-file.c:
qemu_set_offset[611] ret = qio_channel_io_seek(f->ioc, off, whence,
&err);
qemu_get_offset[624] ret = qio_channel_io_seek(f->ioc, 0, SEEK_CUR,
&err);
All these references are about file migrations, not generic live
migrations..
--
Peter Xu
