On Tue, Jun 16, 2026 at 05:01:34PM +0300, Andrey Drobyshev wrote:
Hello Stefano,
On 6/16/26 4:35 PM, Stefano Garzarella wrote:
Hi Andrey,
thanks for the series!
On Fri, Jun 12, 2026 at 07:57:14PM +0300, Andrey Drobyshev wrote:
Host<-->guest connections via AF_VSOCK sockets aren't supposed to
outlive VM migration, since VM is moving to another host. However
there's a special case, which is QEMU live-update, or CPR
(checkpoint-restore) migration. In this case, VM remains on the same
host, and we'd like such connections to persist.
In the spec we have VIRTIO_VSOCK_EVENT_TRANSPORT_RESET which is usually
sent by the device after a migration.
IIUC the specs don't say this has to be done all the time, so we don't
need to change anything in the specs, right?
We just need to avoid sending it (which I think is what we're doing
here... I still need to look at the patches).
Sending this exact ioctl is guarded by one of my patches in the QEMU
counterpart series:
https://lore.kernel.org/qemu-devel/[email protected]/
So we indeed avoid sending it on migration target in case of CPR migration.
Great, so we are aligned :-)
For this to work, we need to be able to transfer device ownership from
source QEMU to dest QEMU. Namely, source needs to reset ownership by
issuing VHOST_RESET_OWNER ioctl, and then target has to claim it by
calling VHOST_SET_OWNER.
Since VHOST_RESET_OWNER isn't yet implemented for vhost-vsock, let's add
such implementation (patches 1-2). Also fix regression introduced by
the earlier commit [1] (patch 3), and fix the deadlock bug (commit 4).
If it's a regression, should we fix it separately?
Or is it related to this series?
Probably my wording wasn't quite correct. I posted this patch here
because we found the problem during testing this particular
functionality, i.e. vsock data transfer + CPR migration. And the
problem was introduced by a recent commit, which is fine on its own, but
breaks the CPR case.
Yeah, I figured out while reviewing the patch.
I'd avoid "regression" here and use just "issue", because at the end is
just affecting this work that is not yet merged, so it can be a
regression.
Thanks,
Stefano
