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/[email protected]/ > ) > > 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
