On 05.02.26 10:07, Markus Armbruster wrote:
Peter Xu <[email protected]> writes:
On Sun, Feb 01, 2026 at 07:19:55PM +0300, Vladimir Sementsov-Ogievskiy wrote:
# @migrate-set-parameters:
@@ -1004,6 +1005,13 @@
# 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 11.0)
I still think it'll be nice to either have "local" in the name of parameter
or at least document it with crystal clear terms.
I used to suggest fd-passing, but maybe you wanted to emphasize there's
more than fds to be migrated at least for tap?
For vhost-user-blk it's the same: not only FDs.
Then it can still be
"local-backend-transfer", because nobody stops a device to transfer backend
states in a remote migration either.. so "backend-transfer" seems to also
work for remote migrations, but it is not.
Hmm. I imagine a mechanism, where OS supports passing FDs to another host.
This needs support for actually migrating the corresponding kernel object
by OS automatically. But theoretically I think it can be done transparently
for userspace QEMU process, which will simply pass FDs to the some special
socket, similar to UNIX domain socket.
So, the key aspect is that we should be able to pass FDs to the migration
channel, which currently meant that it must be UNIX domain socket, and it
must be local migration. But in future it may change.
And yes, "backend-transfer" work for remote migration of backend.
If we ever implement remote backend migration, why not to
reuse "backend-transfer" for it? Even if there will not be transparent
support from OS, and we'll implement another mechanics, we may add
new parameter
backend-transfer-mechanism = "scm-rights" | "something-other"
(or we can put this into "backend-transfer", supporting passing string to
it and deprecating boolean)
More over, this future "remote-backend-transfer" could be used for local
migration, so again, it should be called simply "backend-transfer"..
Or at least mentioned explicitly in the comment, saying this is a local
migration / upgrade.
Documenting the restriction is a must regardless of naming. The
proposed text does document it, but only indirectly: "(which must be a
UNIX socket)". Could be improved, I guess.
Capturing the restriction in the name might help. But it also makes the
name longer. Feels like a matter of taste to me. You guys decide :)
If you could at least update the doc on the locality attribute for the
migration (one way or another..), feel free to take:
Acked-by: Peter Xu <[email protected]>
If you decide to rename, that's even better.
Thanks,
I'm OK with any name, but if you agree with my arguments above, I'd keep
"backend-transfer" name, and update the spec:
@backend-transfer: Enable backend-transfer feature for devices that
support it. In general that means that backend state and its
file descriptors are passed to the destination in the migraton
channel. Individual devices declare the support for
backend-transfer by per-device backend-transfer option.
SCM_RIGHT mechanism used to pass FDs, so backend-transfer
requires migration to be local and the channel to be UNIX domain
socket. (Since 11.0)
--
Best regards,
Vladimir
