From: Peter Xu <peterx@redhat.com>
To: Juraj Marcin <jmarcin@redhat.com>
Cc: qemu-devel@nongnu.org, Mario Casquero <mcasquer@redhat.com>,
Fabiano Rosas <farosas@suse.de>,
"Dr . David Alan Gilbert" <dave@treblig.org>
Subject: Re: [PATCH v3 06/11] migration: Rename save_live_complete_precopy to save_complete
Date: Tue, 24 Jun 2025 11:41:11 -0400 [thread overview]
Message-ID: <aFrHF4hKTdAgRpfs@x1.local> (raw)
In-Reply-To: <oo4t2s5rz4uaivfm3vejlum5c7efsjiysbavtt24rinoefs2tk@ihtornpsiz5q>
On Tue, Jun 24, 2025 at 04:36:39PM +0200, Juraj Marcin wrote:
[...]
> There are still mentions of 'save_live_complete_precopy' in:
>
> include/migration/register.h:100
> * parallel with @save_live_complete_precopy handlers.
> docs/devel/migration/vfio.rst:78
> * A ``save_live_complete_precopy`` function that sets the VFIO device in
> docs/devel/migration/vfio.rst:198
> .save_live_complete_precopy() is called for each active device
> docs/devel/migration/vfio.rst:200
> .save_live_complete_precopy() until
> docs/devel/migration/main.rst:511
> - A ``save_live_complete_precopy`` function that must transmit the
Good catch. If I prepare this fixup to be squashed, can I get your R-b?
From 58147b11276fa193c25f35e63f41a8e34d444dd9 Mon Sep 17 00:00:00 2001
From: Peter Xu <peterx@redhat.com>
Date: Tue, 24 Jun 2025 11:38:17 -0400
Subject: [PATCH] fixup! migration: Rename save_live_complete_precopy to
save_complete
Signed-off-by: Peter Xu <peterx@redhat.com>
---
docs/devel/migration/main.rst | 4 ++--
docs/devel/migration/vfio.rst | 12 ++++++------
include/migration/register.h | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/devel/migration/main.rst b/docs/devel/migration/main.rst
index cdd4f4a6d7..6493c1d2bc 100644
--- a/docs/devel/migration/main.rst
+++ b/docs/devel/migration/main.rst
@@ -508,8 +508,8 @@ An iterative device must provide:
the point that stream bandwidth limits tell it to stop. Each call
generates one section.
- - A ``save_live_complete_precopy`` function that must transmit the
- last section for the device containing any remaining data.
+ - A ``save_complete`` function that must transmit the last section for
+ the device containing any remaining data.
- A ``load_state`` function used to load sections generated by
any of the save functions that generate sections.
diff --git a/docs/devel/migration/vfio.rst b/docs/devel/migration/vfio.rst
index 673e354754..8ff5ab0c74 100644
--- a/docs/devel/migration/vfio.rst
+++ b/docs/devel/migration/vfio.rst
@@ -75,10 +75,10 @@ VFIO implements the device hooks for the iterative approach as follows:
in the non-multifd mode.
In the multifd mode it just emits either a dummy EOS marker.
-* A ``save_live_complete_precopy`` function that sets the VFIO device in
- _STOP_COPY state and iteratively copies the data for the VFIO device until
- the vendor driver indicates that no data remains.
- In the multifd mode it just emits a dummy EOS marker.
+* A ``save_complete`` function that sets the VFIO device in _STOP_COPY
+ state and iteratively copies the data for the VFIO device until the
+ vendor driver indicates that no data remains. In the multifd mode it
+ just emits a dummy EOS marker.
* A ``save_live_complete_precopy_thread`` function that in the multifd mode
provides thread handler performing multifd device state transfer.
@@ -195,9 +195,9 @@ Live migration save path
|
Then the VFIO device is put in _STOP_COPY state
(FINISH_MIGRATE, _ACTIVE, _STOP_COPY)
- .save_live_complete_precopy() is called for each active device
+ .save_complete() is called for each active device
For the VFIO device: in the non-multifd mode iterate in
- .save_live_complete_precopy() until
+ .save_complete() until
pending data is 0
In the multifd mode this iteration is done in
.save_live_complete_precopy_thread() instead.
diff --git a/include/migration/register.h b/include/migration/register.h
index 0510534515..2a26e76a68 100644
--- a/include/migration/register.h
+++ b/include/migration/register.h
@@ -103,7 +103,7 @@ typedef struct SaveVMHandlers {
* Called at the end of a precopy phase from a separate worker thread
* in configurations where multifd device state transfer is supported
* in order to perform asynchronous transmission of the remaining data in
- * parallel with @save_live_complete_precopy handlers.
+ * parallel with @save_complete handlers.
* When postcopy is enabled, devices that support postcopy will skip this
* step.
*
--
2.49.0
>
> Also, should we also drop "live" from
> 'save_live_complete_precopy_thread' as well? IIUC they are called
> together with (now) 'save_complete()' during precopy.
Agreed, though it's better done in a separate one.
If so, wanna send a patch? :)
PS: would be nice if on top of this series, then I can collect them together.
Thanks!
--
Peter Xu
next prev parent reply other threads:[~2025-06-24 15:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 14:07 [PATCH v3 00/11] migration: Some enhancements and cleanups for 10.1 Peter Xu
2025-06-13 14:07 ` [PATCH v3 01/11] migration/hmp: Reorg "info migrate" once more Peter Xu
2025-06-13 14:07 ` [PATCH v3 02/11] migration/hmp: Fix postcopy-blocktime per-vCPU results Peter Xu
2025-06-24 14:28 ` Juraj Marcin
2025-06-13 14:07 ` [PATCH v3 03/11] migration/docs: Move docs for postcopy blocktime feature Peter Xu
2025-06-13 14:07 ` [PATCH v3 04/11] migration/bg-snapshot: Do not check for SKIP in iterator Peter Xu
2025-06-13 14:07 ` [PATCH v3 05/11] migration: Drop save_live_complete_postcopy hook Peter Xu
2025-06-24 14:29 ` Juraj Marcin
2025-06-13 14:07 ` [PATCH v3 06/11] migration: Rename save_live_complete_precopy to save_complete Peter Xu
2025-06-24 14:36 ` Juraj Marcin
2025-06-24 15:41 ` Peter Xu [this message]
2025-06-25 11:13 ` Juraj Marcin
2025-06-25 13:38 ` Peter Xu
2025-06-13 14:07 ` [PATCH v3 07/11] migration: qemu_savevm_complete*() helpers Peter Xu
2025-06-24 14:38 ` Juraj Marcin
2025-06-13 14:07 ` [PATCH v3 08/11] migration/ram: One less indent for ram_find_and_save_block() Peter Xu
2025-06-13 14:07 ` [PATCH v3 09/11] migration/ram: Add tracepoints for ram_save_complete() Peter Xu
2025-06-13 14:08 ` [PATCH v3 10/11] migration: Rewrite the migration complete detect logic Peter Xu
2025-06-13 14:08 ` [PATCH v3 11/11] migration/postcopy: Avoid clearing dirty bitmap for postcopy too Peter Xu
2025-06-25 13:38 ` [PATCH v3 00/11] migration: Some enhancements and cleanups for 10.1 Peter Xu
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=aFrHF4hKTdAgRpfs@x1.local \
--to=peterx@redhat.com \
--cc=dave@treblig.org \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=mcasquer@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).