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
