On 15.10.25 21:19, Peter Xu wrote:
On Wed, Oct 15, 2025 at 04:21:32PM +0300, Vladimir Sementsov-Ogievskiy wrote:
This parameter enables backend-transfer feature: all devices
which support it will migrate their backends (for example a TAP
device, by passing open file descriptor to migration channel).
Currently no such devices, so the new parameter is a noop.
Next commit will add support for virtio-net, to migrate its
TAP backend.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
---
[..]
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -951,9 +951,16 @@
# is @cpr-exec. The first list element is the program's filename,
# the remainder its arguments. (Since 10.2)
#
+# @backend-transfer: Enable backend-transfer feature for devices that
+# supports it. In general that means that backend state and its
+# file descriptors are passed to the destination in the migraton
+# channel (which must be a UNIX socket). Individual devices
+# declare the support for backend-transfer by per-device
+# backend-transfer option. (Since 10.2)
Thanks.
I still prefer the name "fd-passing" or anything more explicit than
"backend-transfer". Maybe the current name is fine for TAP, only because
TAP doesn't have its own VMSD to transfer?
Consider a device that would be a backend that supports VMSDs already to be
migrated, then if it starts to allow fd-passing, this name will stop being
suitable there, because it used to "transfer backend" already, now it's
just started to "fd-passing".
Meanwhile, consider another example - what if a device is not a backend at
all (e.g. vfio?), has its own VMSD, then want to do fd-passing?
Reasonable.
But consider also the discussion with Fabiano in v5, where he argues against fds
(reasonable too):
https://lore.kernel.org/qemu-devel/[email protected]/
(still, they were against my "fds" name for the parameter, which is
really too generic, fd-passing is not)
and the arguments for backend-transfer (to read similar with cpr-transfer)
https://lore.kernel.org/qemu-devel/[email protected]/
In general, I think "fd" is really a core concept of this whole thing.
I think, we can call "backend" any external object, linked by the fd.
Still, backend/frontend terminology is so misleading, when applied to
complex systems (for me, at least), that I don't really like "-backend"
word here.
fd-passing is OK for me, I can resend with it, if arguments by Fabiano
not change your mind.
One
thing to complement that idea is, IMHO this patch misses one important
change, that migration framework should actually explicitly fail the
migration if this feature is enabled but it's not a unix socket protocol
(aka, fd-passing REQUIRES scm rights). Would that look more reliable?
Otherwise IIUC it'll throw weird errors when e.g. when we enabled this
feature and trying to migrate via either TCP or to a file..
Right. I rely on checking in qemu_file_get_fd() / qemu_file_set_fd()
handlers.
But of course, earlier clean failure of qmp-migrate / qmp-incoming-migate
commands would be nice, will do.
Like this, I think:
diff --git a/migration/migration.c b/migration/migration.c
index 6ed6a10f57..0c73332706 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -255,6 +255,14 @@
migration_channels_and_transport_compatible(MigrationAddress *addr,
return false;
}
+ if (migrate_backend_transfer() &&
+ !(addr->transport == MIGRATION_ADDRESS_TYPE_SOCKET &&
+ addr->u.socket.type == SOCKET_ADDRESS_TYPE_UNIX)) {
+ error_setg(errp, "Migration requires a UNIX domain socket as transport,
"
+ "because backend-transfer is enabled");
+ return false;
+ }
+
return true;
}
--
Best regards,
Vladimir
