diff options
| author | Wei Yang <richardw.yang@linux.intel.com> | 2019-06-12 09:43:37 +0800 |
|---|---|---|
| committer | Juan Quintela <quintela@redhat.com> | 2019-07-15 15:39:02 +0200 |
| commit | b6526c4b2122138833dacf7da74caabb84177344 (patch) | |
| tree | 052ff62b9f4bdd82e387a79692e021b2ca22520f /migration/ram.c | |
| parent | 8f7798f191117691853f4c65efca24a60bb2ff80 (diff) | |
| download | qemu-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.c | 2 |
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; |