On 8/7/25 9:13 AM, Peter Xu wrote:
On Thu, Aug 07, 2025 at 08:50:38AM -0400, Jonah Palmer wrote:
On 8/6/25 11:58 AM, Peter Xu wrote:
On Tue, Jul 22, 2025 at 12:41:22PM +0000, Jonah Palmer wrote:
Adds a new migration capability 'virtio-iterative' that will allow
virtio devices, where supported, to iteratively migrate configuration
changes that occur during the migration process.
This capability is added to the validated capabilities list to ensure
both the source and destination support it before enabling.
The capability defaults to off to maintain backward compatibility.
To enable the capability via HMP:
(qemu) migrate_set_capability virtio-iterative on
To enable the capability via QMP:
{"execute": "migrate-set-capabilities", "arguments": {
"capabilities": [
{ "capability": "virtio-iterative", "state": true }
]
}
}
Signed-off-by: Jonah Palmer <jonah.pal...@oracle.com>
---
migration/savevm.c | 1 +
qapi/migration.json | 7 ++++++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/migration/savevm.c b/migration/savevm.c
index bb04a4520d..40a2189866 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -279,6 +279,7 @@ static bool should_validate_capability(int capability)
switch (capability) {
case MIGRATION_CAPABILITY_X_IGNORE_SHARED:
case MIGRATION_CAPABILITY_MAPPED_RAM:
+ case MIGRATION_CAPABILITY_VIRTIO_ITERATIVE:
return true;
default:
return false;
diff --git a/qapi/migration.json b/qapi/migration.json
index 4963f6ca12..8f042c3ba5 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -479,6 +479,11 @@
# each RAM page. Requires a migration URI that supports seeking,
# such as a file. (since 9.0)
#
+# @virtio-iterative: Enable iterative migration for virtio devices, if
+# the device supports it. When enabled, and where supported, virtio
+# devices will track and migrate configuration changes that may
+# occur during the migration process. (Since 10.1)
+#
Having a migration capability to enable iterative support for a specific
type of device sounds wrong.
If virtio will be able to support iterative saves, it could provide the
save_live_iterate() function. Any explanation why it needs to be a
migration capability?
It certainly doesn't have to be a migration capability. Perhaps it's better
as a per-device compatibility property? E.g.:
-device virtio-net-pci,x-iterative-migration=on,...
I was just thinking along the lines of not having this feature enabled by
default for backwards-compatibility (and something to toggle to compare
performance during development).
Totally open to suggestions though. I wasn't really sure how best a
feature/capability like this should be introduced.
Yep, for RFC is fine, if there'll be a formal patch please propose it as a
device property whenever needed, thanks.
Gotcha, will do! Thanks for the suggestion :)
Jonah
