On 6/29/2026 7:27 PM, Peter Xu wrote:
External email: Use caution opening links or attachments
On Mon, Jun 29, 2026 at 06:53:48PM +0300, Avihai Horon wrote:
On 6/29/2026 5:57 PM, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
Avihai
On 6/28/26 18:29, Cédric Le Goater wrote:
On 6/28/26 12:03, Avihai Horon wrote:
On 6/28/2026 12:00 PM, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 6/28/26 10:16, Avihai Horon wrote:
On 6/26/2026 10:54 AM, Markus Armbruster wrote:
External email: Use caution opening links or attachments
Just spelling nitpickery this time.
Avihai Horon <[email protected]> writes:
Switchover-ack is a mechanism to synchronize between source and
destination QEMU during migration to prevent the
source from switching
over prematurely.
VFIO uses switchover-ack to ensure switchover happens only after
destination side has loaded the precopy initial
bytes. This is important
for VFIO, as otherwise downtime could be impacted and be higher.
In its current state, switchover-ack is a
one-time mechanism, meaning
that switchover is acked only once and past that
another ACK cannot be
requested again. This was sufficient until now,
as VFIO precopy initial
bytes was defined to be monotonically
decreasing. Thus, when precopy
initial bytes reached zero for all VFIO devices,
a single ACK would be
sent and its validity would hold.
However, now the new VFIO_PRECOPY_INFO_REINIT
feature allows precopy
initial bytes to be re-initialized during precopy. Specifically, it
means that initial bytes can grow after reaching zero, which would
invalidate a previously sent switchover ACK.
To solve this, make switchover-ack reusable and
allow devices to request
switchover ACKs when needed via the
save_query_pending SaveVMHandler.
Since now switchover ACK can be requested for a
specific device and in
different times, make switchover ACK per-device
(instead of a single ACK
for all devices) and let source side do the
pending ACKs accounting.
Keep the legacy switchover-ack mechanism for
backward compatibility and
turn it on by a compatibility property for older
machines. Enable the
property until VFIO implements the new switchover-ack.
Acked-by: Markus Armbruster <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Signed-off-by: Avihai Horon <[email protected]>
---
qapi/migration.json | 14 ++++----
include/migration/client-options.h | 1 +
include/migration/register.h | 2 ++
migration/migration.h | 32 ++++++++++++++++--
migration/savevm.h | 6 ++--
migration/migration.c | 37 ++++++++++++++-------
migration/options.c | 10 ++++++
migration/savevm.c | 53
+++++++++++++++++++++++-------
migration/trace-events | 5 +--
9 files changed, 123 insertions(+), 37 deletions(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 27a7970556..9b3070e494 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -508,14 +508,12 @@
# (since 7.1)
#
# @switchover-ack: If enabled, migration will
not stop the source VM
-# and complete the migration until an ACK is received from the
-# destination that it's OK to do so. Exactly when this ACK is
-# sent depends on the migrated devices that
use this feature. For
-# example, a device can use it to make sure
some of its data is
-# sent and loaded in the destination before doing switchover.
Here, "switchover" is used as noun. My dictionary
is happy with that.
-# This can reduce downtime if devices that
support this capability
-# are present. 'return-path' capability
must be enabled to use
-# it. (since 8.1)
+# and complete the migration until the destination has
+# acknowledged that it is OK to
switchover. The acknowledgement
Here, it's used as verb. I think it needs to be spelled "to switch
over".
Same for code comments etc.
Sure, I can send a patch to fix those.
Can you please send the update as a follow up patch ?
I was planning to send it along with the bool return value
refactor in patch #1. Would that be fine?
OK. Nothing merged yet. Let's have a v5.
FYI, I plan to send vfio-next before the end the week. Initial plan was
tomorrow.
Hi Cedric,
Actually, I have plenty of things on my plate right now and I'm not sure if
I'll be able to send it this week.
Would it be OK if you merge the series as is and I send those two patches
separately early next week?
(They are actually more related to migration core, so this question should
be addressed to Peter/Fabiano I guess...)
I'm OK either way.
The simplest to me is you can provide a small fixup for Cédric to pick up
and squash into this patch (if it's only wording changes to doc and
comments, IMHO no re-test needed), as long as Cédric is comfortable with
it, then you can send a separate patch (or patches) if that'll be on
migration.
I think I'll send those two patches separately later (since the wording
patch fixes a few other places too).
Thank you both.
