Re: [RFC v2 04/14] virtio-net: detect VirtIODevice status mid-migration change

[Eugenio Perez Martin <eperezma@redhat.com>]

On Tue, Mar 24, 2026 at 4:02 PM Jonah Palmer <jonah.palmer@oracle.com> wrote:
>
>
>
> On 3/24/26 6:45 AM, Eugenio Perez Martin wrote:
> > On Fri, Mar 20, 2026 at 3:20 PM Jonah Palmer <jonah.palmer@oracle.com> wrote:
> >>
> >> This patch introduces the mechanism in which this series will use to
> >> detect VirtIODevice & VirtIONet state deltas, starting with the
> >> VirtIODevice's 'status' member of a virtio-net device.
> >>
> >> Before we send the device's state early, we save each piece of its state
> >> in a temporary structure via virtio_net_early_pre_save. Later, once the
> >> source VM has been paused,
> >
> > While I ack this approach should cover 99% of cases—as I think it is
> > unlikely the guest changes device properties during a live migration—I
> > still believe these changes should be sent when the guest modifies the
> > property, before it is paused. That way we shrink the downtime even
> > more. This comparison fits naturally: Instead of sending one state and
> > then the deltas at the switchover, we send the state and then the
> > delta for every change.
> >
> > However, I'm happy enough with this approach because it is more
> > self-contained within the migration code. It also reduces the state
> > sent over the migration channel if the guest changes its device status
> > many times.
> >
> > CCing Juraj as we discussed this at the virtio-net upstream meeting.
> >
>
> Right. I agree it would be optimal that, for every change made during
> live migration, the destination is updated with this change and it's not
> left to be handled once the source has been paused, which would impact
> guest-visible downtime (especially if it's an expensive change).
>
> However, the only way to handle mid-migration changes like this is via
> the SaveVMHandlers framework. I did give a stab at this approach in my
> v1 RFC series:
> https://lore.kernel.org/qemu-devel/20250722124127.2497406-1-jonah.palmer@oracle.com/
>
> However, Peter believed that this early-migration work would be better
> suited using the VMStateDescription framework instead. And the VMSD
> framework does not support handling these mid-migration changes before
> the stop-and-copy phase.
>

Right. But we can extend the VMStateDescription framework to support
asynchronous state sending as well. At first glance, it should just
add a new VMStateDescription to the struct SaveStateEntry, let's call
it live_vmsd, and call it at the same function that calls
SaveVMHandlers->save_live_iterate, which is
migration/savevm.c:qemu_savevm_state_iterate. The load version also
needs to be called when .load_state is called.

While this extends the series, I think little code is needed and I
believe it's the right long-term decision to avoid adding multiple
ways to solve the same problem. Again, is this ".early" version is the
best we can do, I'm pretty sure it solves most of the cases so, sure,
I'm all in :).