On Wed, Jan 14, 2026 at 09:19:10AM +0300, Vladimir Sementsov-Ogievskiy wrote: > On 13.01.26 21:56, Peter Xu wrote: > > On Tue, Jan 13, 2026 at 01:12:42PM -0500, Stefan Hajnoczi wrote: > > > On Tue, Jan 13, 2026 at 02:58:09PM +0500, Alexandr Moshkov wrote: > > > > > > Peter: Please review the migration aspects (especially the vmstates). > > > Thank you! > > > > Looks good from my side as long as it's based on VMSD, I appreciate that > > change from the old versions where it used to use qemufile APIs. > > > > The major question here is if this series depends on Vladimir's other > > series > > No, it does not. And if we can proceed with merging these series first, I'll > be happy to rebase on top of it.
I thought it requires migrate_local_vhost_user_blk() be present? The inflight feature should not be enabled only if there's a hint that it's a local migration.. I'll comment inline on the patch later. > > > while there's still one patch that is not-for-merge: > > > > https://lore.kernel.org/all/[email protected]/#t > > > > Does it automatically mark this series RFC as well? > > > > Personally speaking, a new migration cap would work all fine, we should > > have discussed it somewhere previously. Said that, "local-vhost-user-blk" > > capability is likely not the right one. IMHO it should be either "local" > > or "fd-passing" / "fd-passthrough" (or something generic) as the name. If > > we are not sure if we will leverage more than "passing the FDs around", we > > can make it as simple as "local" as a new migration capability. > > > > Then migration's misc.h should export a function migrate_is_local() then > > device code can probe that in its own vmstate handling paths on save/load. > > > > A note to Vladimir: please remember to add a check to enforce UNIX socket > > when a formal patch 23 will be proposed some day, no matter what is the > > name of the capability. It should fail qmp "migrate" or qmp > > "migrate_incoming" command if the main URI is not a unix socket. > > > > Thanks! I'll keep that in mind when prepare next version. > > -- > Best regards, > Vladimir > -- Peter Xu
