aboutsummaryrefslogtreecommitdiff
path: root/migration/ram.c
diff options
context:
space:
mode:
authorWei Yang <richardw.yang@linux.intel.com>2019-06-12 09:43:37 +0800
committerJuan Quintela <quintela@redhat.com>2019-07-15 15:39:02 +0200
commitb6526c4b2122138833dacf7da74caabb84177344 (patch)
tree052ff62b9f4bdd82e387a79692e021b2ca22520f /migration/ram.c
parent8f7798f191117691853f4c65efca24a60bb2ff80 (diff)
downloadqemu-b6526c4b2122138833dacf7da74caabb84177344.zip
qemu-b6526c4b2122138833dacf7da74caabb84177344.tar.gz
qemu-b6526c4b2122138833dacf7da74caabb84177344.tar.bz2
migration/multifd: call multifd_send_sync_main when sending RAM_SAVE_FLAG_EOS
On receiving RAM_SAVE_FLAG_EOS, multifd_recv_sync_main() is called to synchronize receive threads. Current synchronization mechanism is to wait for each channel's sem_sync semaphore. This semaphore is triggered by a packet with MULTIFD_FLAG_SYNC flag. While in current implementation, we don't do multifd_send_sync_main() to send such packet when blk_mig_bulk_active() is true. This will leads to the receive threads won't notify multifd_recv_sync_main() by sem_sync. And multifd_recv_sync_main() will always wait there. [Note]: normal migration test works, while didn't test the blk_mig_bulk_active() case. Since not sure how to produce this situation. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190612014337.11255-1-richardw.yang@linux.intel.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
Diffstat (limited to 'migration/ram.c')
-rw-r--r--migration/ram.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/migration/ram.c b/migration/ram.c
index 908517f..74c9306 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3466,8 +3466,8 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
*/
ram_control_after_iterate(f, RAM_CONTROL_ROUND);
- multifd_send_sync_main();
out:
+ multifd_send_sync_main();
qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
qemu_fflush(f);
ram_counters.transferred += 8;