Branch: refs/heads/staging-9.1
Home: https://github.com/qemu/qemu
Commit: 8dfef83d6a551ef02b7a51c2e00c57fe52d1a2e1
https://github.com/qemu/qemu/commit/8dfef83d6a551ef02b7a51c2e00c57fe52d1a2e1
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix parsing of s390 stream
The parsing for the S390StorageAttributes section is currently leaving
an unconsumed token that is later interpreted by the generic code as
QEMU_VM_EOF, cutting the parsing short.
The migration will issue a STATTR_FLAG_DONE between iterations, which
the script consumes correctly, but there's a final STATTR_FLAG_EOS at
.save_complete that the script is ignoring. Since the EOS flag is a
u64 0x1ULL and the stream is big endian, on little endian hosts a byte
read from it will be 0x0, the same as QEMU_VM_EOF.
Fixes: 81c2c9dd5d ("tests/qtest/migration-test: Fix analyze-migration.py for
s390x")
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 69d1f784569fdb950f2923c3b6d00d7c1b71acc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c5f902eed185a11903e8344334ee3add7cffd562
https://github.com/qemu/qemu/commit/c5f902eed185a11903e8344334ee3add7cffd562
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x: Fix CSS migration
Commit a55ae46683 ("s390: move css_migration_enabled from machine to
css.c") disabled CSS migration globally instead of doing it
per-instance.
CC: Paolo Bonzini <[email protected]>
CC: [email protected] #9.1
Fixes: a55ae46683 ("s390: move css_migration_enabled from machine to css.c")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2704
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit c76ee1f6255c3988a9447d363bb17072f1ec84e1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9f922d0c3e3f60a8e91300ab60fbc99174579638
https://github.com/qemu/qemu/commit/9f922d0c3e3f60a8e91300ab60fbc99174579638
Author: Yuan Liu <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M migration/multifd.c
Log Message:
-----------
multifd: bugfix for migration using compression methods
When compression is enabled on the migration channel and
the pages processed are all zero pages, these pages will
not be sent and updated on the target side, resulting in
incorrect memory data on the source and target sides.
The root cause is that all compression methods call
multifd_send_prepare_common to determine whether to compress
dirty pages, but multifd_send_prepare_common does not update
the IOV of MultiFDPacket_t when all dirty pages are zero pages.
The solution is to always update the IOV of MultiFDPacket_t
regardless of whether the dirty pages are all zero pages.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the
multifd thread.")
Cc: [email protected] #9.0+
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit cdc3970f8597ebdc1a4c2090cfb4d11e297329ed)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: in 9.1 this code is in migration/multifd.c, not in
migration/multifd-nocomp.c)
Commit: afc57aa338129b4f91fc4caabd3a02afbfb64004
https://github.com/qemu/qemu/commit/afc57aa338129b4f91fc4caabd3a02afbfb64004
Author: Yuan Liu <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M migration/multifd-qpl.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with QPL compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2588a5f99b0c3493b4690e3ff01ed36f80e830cc)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/e85081d81f5b...afc57aa33812
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
