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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.