On Wed, Oct 15, 2025 at 10:02:14PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 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.
Ah, I didn't notice the name has been discussed.
I think it means you can vote for your own preference now because we have
one vote for each. :) Let's also see whether Fabiano will come up with
something better than both.
You mentioned explicitly the file descriptors in the qapi doc, that's what
I would strongly request for. The other thing is the unix socket check, it
looks all good below now with it, thanks. No strong feelings on the names.
>
> > 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
>
--
Peter Xu
