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
