colo: Do not hold the BQL while receiving ram state.
We only receive ram into the colo cache here and don't touch anything else, so the BQL is not needed here. Move cpu_synchronize_all_states() downwards, before we apply the received checkpoint. It turns out that qemu_system_reset() already calls it for us. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Lukas Straub <lukasstraub2@web.de> Link: https://lore.kernel.org/qemu-devel/20260302-colo_unit_test_multifd-v11-12-d653fb3b1d80@web.de Signed-off-by: Fabiano Rosas <farosas@suse.de>
Lukas Straub committed
Mar 2, 2026 at 12:45 UTC
9d13dd0a509bc21f6d9c25cc0331d3d51067edf0
1 file changed
+2
-4
migration/colo.c
+2
-4
@@ -686,11 +686,7 @@ static void colo_incoming_process_checkpoint(MigrationIncomingState *mis,
686
return;
687
}
688
689
- bql_lock();
690
- cpu_synchronize_all_states();
689
ret = qemu_loadvm_state_main(mis->from_src_file, mis, errp);
692
- bql_unlock();
693
-
690
if (ret < 0) {
691
return;
692
}
@@ -733,6 +729,8 @@ static void colo_incoming_process_checkpoint(MigrationIncomingState *mis,
729
* With colo we load device vmstate during each checkpoint, on top of
730
* a vm that was already running. Some devices expect a reset before
731
* loading vmstate on such a previously running vm.
732
+ *
733
+ * NOTE: qemu_system_reset() calls cpu_synchronize_all_states() for us
734
*/
735
qemu_system_reset(SHUTDOWN_CAUSE_SNAPSHOT_LOAD);
736
colo_flush_ram_cache();