On 14.10.25 16:40, Daniel P. Berrangé wrote:
On Mon, Oct 13, 2025 at 04:38:29PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
That's a preparation for backend-transfer migration of
vhost-user-blk. For such migration we are going to transfer
vhost-user-blk fds, including backend chardev fd to the target
in migration stream (backed by UNIX domain socket).
So, on the target, we want to know, should we call connect(),
or is it a backend-transfer migration, and we should wait for
incoming fd.
But at initialization time we can't know it: user may setup
migration parameters (enabling backend-transfer) later.
So, let's postpone chardev open/connect phase up to attaching
to frontend. At this point we can check:
- if it's vhost-user-blk, do nothing, let vhost-user-blk decide
when to do connect()
- otherwise, do connect() at this point
I'm finding it quite unpleasant that we've created a new set of
callbacks just for the socket backend, and not the other chardev
backends.
Conceptually it feels like the problem of transferring in pre-
opened FDs from a previous QEMU should be conceptually relevant
to all the backend types. If it is, then I very much want us to
convert all the backends instead of leaving a pile of technical
debt for someone else in the future.
Agree. If the design is approved, I'll try to update all other
chardevs as well.
This series also doesn't illustrate usage of the new model with
pre-opened FDs, so I'm finding it hard to validate whether
this design is effective or not.
Understand, of course.
[PATCH v2 00/?] vhost-user-blk: live-backend local migration
is coming soon, so the whole picture will be seen.
Still, I'll first resend this one (chardev: postpone connect) and
[PATCH v2 00/23] vhost refactoring and fixes
to base future v2 vhost-user-blk: live-backend local migration
on clear base.
--
Best regards,
Vladimir
