Re: [PATCH v8 16/19] qapi: introduce backend-transfer migration parameter

[Peter Xu <peterx@redhat.com>]

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 <vsementsov@yandex-team.ru>
> > > ---
> 
> [..]
> 
> > > --- 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/87y0qatqoa.fsf@suse.de/
> 
> (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/87ms6qtlgf.fsf@suse.de/
> 
> 
> > 
> > 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