aboutsummaryrefslogtreecommitdiff
path: root/hw/m68k/next-cube.c
diff options
context:
space:
mode:
authorFabiano Rosas <farosas@suse.de>2024-08-27 14:46:00 -0300
committerFabiano Rosas <farosas@suse.de>2024-09-03 16:24:36 -0300
commita0c78d815c34e81feedae60347734d28b1098a27 (patch)
tree69da0a7db9dba82fe711eee21a00795d551cf164 /hw/m68k/next-cube.c
parenta71ef5c7f329533a49ab164b92945267be864ede (diff)
downloadqemu-a0c78d815c34e81feedae60347734d28b1098a27.zip
qemu-a0c78d815c34e81feedae60347734d28b1098a27.tar.gz
qemu-a0c78d815c34e81feedae60347734d28b1098a27.tar.bz2
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 'hw/m68k/next-cube.c')
0 files changed, 0 insertions, 0 deletions