Re: [PATCH v6 0/5] support inflight migration

On 14.01.26 15:22, Peter Xu wrote:
> 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..

Oh right, I missed it.

We discussed that Alexandr will rebase the series on master without dependency
on my RFC.

> 
> 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
>>
> 


-- 
Best regards,
Vladimir