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

Vladimir Sementsov-Ogievskiy <[email protected]> Wed, 14 Jan 2026 20:54:50 +0300
Newsgroups dev.linux.lists.virtio-fs,org.nongnu.qemu-devel
Message-ID <[email protected]>
On 14.01.26 18:17, Peter Xu wrote:
> On Wed, Jan 14, 2026 at 05:35:53PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> 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.
> 
> The problem is IIUC the new INFLIGHT feature bit will be declared as
> supported to vhost-user-block after applying this series.  Then if we start
> a remote migration (rather than local) it'll be automatically (and wrongly)
> enabled?
> 

No, not so.

We develop inflight-region migraiton (this series) exactly for remote migration,
not for local.

My series about backend transfer (fd-migration) will migrate inflight-region the
other way - by migrating its FD.

> AFAIU, the dependency makes sense, at least to the patch to introduce the
> "local" / ... capability?
> 


-- 
Best regards,
Vladimir