Re: [PATCH v3 0/3] vhost-user-blk: support inflight migration

[Peter Xu <peterx@redhat.com>]

On Tue, Nov 18, 2025 at 11:24:12PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Add Daniel
> 
> On 10.11.25 13:39, Alexandr Moshkov wrote:
> > v3:
> > - use pre_load_errp instead of pre_load in vhost.c
> > - change vhost-user-blk property to
> >    "skip-get-vring-base-inflight-migration"
> > - refactor vhost-user-blk.c, by moving vhost_user_blk_inflight_needed() higher
> > 
> > v2:
> > - rewrite migration using VMSD instead of qemufile API
> > - add vhost-user-blk parameter instead of migration capability
> > 
> > I don't know if VMSD was used cleanly in migration implementation, so
> > feel free for comments.
> > 
> > Based on Vladimir's work:
> > [PATCH v2 00/25] vhost-user-blk: live-backend local migration
> >    which was based on:
> >      - [PATCH v4 0/7] chardev: postpone connect
> >        (which in turn is based on [PATCH 0/2] remove deprecated 'reconnect' options)
> >      - [PATCH v3 00/23] vhost refactoring and fixes
> >      - [PATCH v8 14/19] migration: introduce .pre_incoming() vmsd handler
> > 
> 
> Hi!
> 
> On my series about backend-transfer migration, the final consensus (or at least,
> I hope that it's a consensus:) is that using device properties to control migration
> channel content is wrong. And we should instead use migration parameters.
> 
> (discussion here: https://lore.kernel.org/qemu-devel/29aa1d66-9fa7-4e44-b0e3-2ca26e77accf@yandex-team.ru/ )
> 
> So the API for backend-transfer features is a migration parameter
> 
>     backend-transfer = [ list of QOM paths of devices, for which we want to enable backend-transfer ]
> 
> and user don't have to change device properties in runtime to setup the following migration.
> 
> So I assume, similar practice should be applied here: don't use device
> properties to control migration.
> 
> So, should it be a parameter like
> 
>     migrate-inflight-region = [ list of QOM paths of vhost-user devices ]
> 
> ?

I have concern that if we start doing this more, migration qapi/ will be
completely messed up.

Imagine a world where there'll be tons of lists like:

  migrate-dev1-some-feature-1 = [list of devices (almost only dev1 typed)]
  migrate-dev2-some-feature-2 = [list of devices (almost only dev2 typed)]
  migrate-dev3-some-feature-3 = [list of devices (almost only dev3 typed)]
  ...

That doesn't look reasonable at all.  If some feature is likely only
supported in one device, that should not appear in migration.json but only
in the specific device.

I don't think I'm fully convinced we can't enable some form of machine type
properties (with QDEV or not) on backends we should stick with something
like that.  I can have some closer look this week, but.. even if not, I
still think migration shouldn't care about some specific behavior of a
specific device.

If we really want to have some way to probe device features, maybe we
should also think about a generic interface (rather than "one new list
every time").  We also have some recent discussions on a proper interface
to query TAP backend features like USO*.  Maybe they share some of the
goals here.

Thanks,

-- 
Peter Xu