From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
To: Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Avihai Horon" <avihaih@nvidia.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
qemu-devel@nongnu.org
Subject: [PATCH 0/4] Trivial patches from multifd device state transfer support patch set
Date: Tue, 29 Oct 2024 15:58:12 +0100 [thread overview]
Message-ID: <cover.1730203967.git.maciej.szmigiero@oracle.com> (raw)
From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
A new version of the multifd device state transfer support with VFIO consumer
patch set is being prepared, the previous version and the associated
discussion is available here:
https://lore.kernel.org/qemu-devel/cover.1724701542.git.maciej.szmigiero@oracle.com/
This new version was originally targeting QEMU 9.2 but such schedule proved
to be too optimistic due to sheer number of invasive changes/rework required,
especially with respect to the VFIO internal threads management and their
synchronization with the migration core.
In addition to these changes, recently merged commit 3b5948f808e3
("vfio/migration: Report only stop-copy size in vfio_state_pending_exact()")
seems to have uncovered a race between multifd RAM and device state transfers:
RAM transfer sender finishes the multifd stream with a SYNC in
ram_save_complete() but the multifd receive channels are only released
from this SYNC after the migration is wholly complete in
process_incoming_migration_bh().
The above causes problems if the multifd channels need to still be
running after the RAM transfer is completed, for example because
there is still remaining device state to be transferred.
Since QEMU 9.2 code freeze is coming I've separated small uncontroversial
commits from that WiP main patch set here, some of which were already
reviewed during previous main patch set iterations.
This way at least future code conflicts can be reduced and the amount
of patches that need to be carried in the future versions of the main
patch set is reduced.
Maciej S. Szmigiero (4):
vfio/migration: Add save_{iterate,complete_precopy}_started trace
events
migration/ram: Add load start trace event
migration/multifd: Zero p->flags before starting filling a packet
migration: Document the BQL behavior of load SaveVMHandlers
hw/vfio/migration.c | 13 +++++++++++++
hw/vfio/trace-events | 3 +++
include/hw/vfio/vfio-common.h | 3 +++
include/migration/register.h | 4 ++++
migration/multifd.c | 2 +-
migration/ram.c | 1 +
migration/trace-events | 1 +
7 files changed, 26 insertions(+), 1 deletion(-)
next reply other threads:[~2024-10-29 15:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 14:58 Maciej S. Szmigiero [this message]
2024-10-29 14:58 ` [PATCH 1/4] vfio/migration: Add save_{iterate, complete_precopy}_started trace events Maciej S. Szmigiero
2024-10-31 14:21 ` [PATCH 1/4] vfio/migration: Add save_{iterate,complete_precopy}_started " Avihai Horon
2024-10-31 22:17 ` Maciej S. Szmigiero
2024-11-01 16:48 ` Maciej S. Szmigiero
2024-11-04 8:08 ` Avihai Horon
2024-11-04 14:00 ` Maciej S. Szmigiero
2024-11-04 14:10 ` Avihai Horon
2024-10-29 14:58 ` [PATCH 2/4] migration/ram: Add load start trace event Maciej S. Szmigiero
2024-10-29 19:10 ` Fabiano Rosas
2024-10-29 14:58 ` [PATCH 3/4] migration/multifd: Zero p->flags before starting filling a packet Maciej S. Szmigiero
2024-10-29 14:58 ` [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers Maciej S. Szmigiero
2024-10-29 19:26 ` Fabiano Rosas
2024-10-29 20:35 ` Peter Xu
2024-10-29 20:46 ` Maciej S. Szmigiero
2024-10-29 21:04 ` Peter Xu
2024-10-29 20:40 ` [PATCH 0/4] Trivial patches from multifd device state transfer support patch set Peter Xu
2024-10-29 20:46 ` Maciej S. Szmigiero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1730203967.git.maciej.szmigiero@oracle.com \
--to=mail@maciej.szmigiero.name \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=joao.m.martins@oracle.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).