aboutsummaryrefslogtreecommitdiff
path: root/qapi/string-input-visitor.c
diff options
context:
space:
mode:
authorPeter Xu <peterx@redhat.com>2024-12-06 17:47:50 -0500
committerFabiano Rosas <farosas@suse.de>2025-01-09 17:38:12 -0300
commit10801e08ac926a5a6083a9bd2ff87b153ccb95b1 (patch)
tree2593e5e0726ad3e8253758512137bf146cb1a764 /qapi/string-input-visitor.c
parent1d457daf868191dc1c0b58dc7280799964f40334 (diff)
downloadqemu-10801e08ac926a5a6083a9bd2ff87b153ccb95b1.zip
qemu-10801e08ac926a5a6083a9bd2ff87b153ccb95b1.tar.gz
qemu-10801e08ac926a5a6083a9bd2ff87b153ccb95b1.tar.bz2
migration/multifd: Allow to sync with sender threads only
Teach multifd_send_sync_main() to sync with threads only. We already have such requests, which is when mapped-ram is enabled with multifd. In that case, no SYNC messages will be pushed to the stream when multifd syncs the sender threads because there's no destination threads waiting for that. The whole point of the sync is to make sure all threads finished their jobs. So fundamentally we have a request to do the sync in different ways: - Either to sync the threads only, - Or to sync the threads but also with the destination side. Mapped-ram did it already because of the use_packet check in the sync handler of the sender thread. It works. However it may stop working when e.g. VFIO may start to reuse multifd channels to push device states. In that case VFIO has similar request on "thread-only sync" however we can't check a flag because such sync request can still come from RAM which needs the on-wire notifications. Paving way for that by allowing the multifd_send_sync_main() to specify what kind of sync the caller needs. We can use it for mapped-ram already. No functional change intended. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241206224755.1108686-3-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Diffstat (limited to 'qapi/string-input-visitor.c')
0 files changed, 0 insertions, 0 deletions