diff options
| author | Fabiano Rosas <farosas@suse.de> | 2024-08-27 14:46:00 -0300 |
|---|---|---|
| committer | Fabiano Rosas <farosas@suse.de> | 2024-09-03 16:24:36 -0300 |
| commit | a0c78d815c34e81feedae60347734d28b1098a27 (patch) | |
| tree | 69da0a7db9dba82fe711eee21a00795d551cf164 /migration/multifd.h | |
| parent | a71ef5c7f329533a49ab164b92945267be864ede (diff) | |
migration/multifd: Allow multifd sync without flush
Separate the multifd sync from flushing the client data to the
channels. These two operations are closely related but not strictly
necessary to be executed together.
The multifd sync is intrinsic to how multifd works. The multiple
channels operate independently and may finish IO out of order in
relation to each other. This applies also between the source and
destination QEMU.
Flushing the data that is left in the client-owned data structures
(e.g. MultiFDPages_t) prior to sync is usually the right thing to do,
but that is particular to how the ram migration is implemented with
several passes over dirty data.
Make these two routines separate, allowing future code to call the
sync by itself if needed. This also allows the usage of
multifd_ram_send to be isolated to ram code.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Diffstat (limited to 'migration/multifd.h')
| -rw-r--r-- | migration/multifd.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/migration/multifd.h b/migration/multifd.h index 5fa384d9af..00c872dfda 100644 --- a/migration/multifd.h +++ b/migration/multifd.h @@ -270,4 +270,5 @@ static inline uint32_t multifd_ram_page_count(void) void multifd_ram_save_setup(void); void multifd_ram_save_cleanup(void); +int multifd_ram_flush_and_sync(void); #endif |