qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 16/24] migration/multifd: Send final SYNC only after devic


From: Peter Xu
Subject: Re: [PATCH v3 16/24] migration/multifd: Send final SYNC only after device state is complete
Date: Wed, 11 Dec 2024 08:20:52 -0500

On Wed, Dec 11, 2024 at 12:05:40AM +0100, Maciej S. Szmigiero wrote:
> > I sent two small patches here:
> > 
> > 20241205185303.897010-1-peterx@redhat.com">https://lore.kernel.org/r/20241205185303.897010-1-peterx@redhat.com
> > 
> > The 1st patch should fix the SYNC message hang for 637280aeb2 that I did.
> > The 2nd patch introduced the flag that I said.  I think after that applied
> > VFIO should be able to sync directly with:
> > 
> >    multifd_send_sync_main(MULTIFD_SYNC_THREADS);
> > 
> > Then maybe we don't need this patch anymore.  Please have a look.
> > 
> > PS: the two patches could be ready to merge already even before VFIO, if
> > they're properly reviewed and acked.
> 
> Thanks Peter for this alternate solution
> 
> I think/hope that by the time I will be preparing the next version of
> this patch multifd device state set these SYNC patches will be already
> merged and I can develop/test against them.

Yes that's the plan, even if it didn't yet land you can also collect the
first two patches, especially if you agree with the changes.  I think we
should fix it one way or another, so basing on top of that might be best
for this series (it should hopefully have less code to change with that).

Just to mention: when rebased on top, multifd_send_sync_main() may or may
not need a lock to protect when VFIO uses it.  I think no, as long as it
always comes from the migration thread, but worth double check as I don't
100% know what's the next version looks like (or it can simply share the
same multifd mutex, I think).

Thanks,

-- 
Peter Xu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]