On Tue, Nov 05, 2024 at 03:31:19PM +0530, Prasad Pandit wrote:
> On Mon, 4 Nov 2024 at 22:30, Peter Xu wrote:
> > Yes, IMHO it's better when merged.
> >
> > One more note here, that even with ZERO_PAGE_DETECTION_MULTIFD, qemu will
> > fallback to use LEGACY in reality when !multifd before. We nee
On Mon, 4 Nov 2024 at 22:30, Peter Xu wrote:
> Yes, IMHO it's better when merged.
>
> One more note here, that even with ZERO_PAGE_DETECTION_MULTIFD, qemu will
> fallback to use LEGACY in reality when !multifd before. We need to keep
> that behavior.
* Where does this fallback happen? in ram_sav
On Mon, Nov 04, 2024 at 05:26:45PM +0530, Prasad Pandit wrote:
> On Fri, 1 Nov 2024 at 20:09, Peter Xu wrote:
> > > +if (migrate_multifd()) {
> > > +RAMBlock *block = pss->block;
> > > +/*
> > > + * While using multifd live migration, we still need to handle
> > > zero
On Fri, 1 Nov 2024 at 20:09, Peter Xu wrote:
> > +if (migrate_multifd()) {
> > +RAMBlock *block = pss->block;
> > +/*
> > + * While using multifd live migration, we still need to handle zero
> > + * page checking on the migration main thread.
> > + */
>
On Tue, Oct 29, 2024 at 08:39:07PM +0530, Prasad Pandit wrote:
> From: Prasad Pandit
>
> Refactor ram_save_target_page legacy and multifd
> functions into one. Other than simplifying it,
> it avoids reinitialization of the 'migration_ops'
> object, when migration moves from multifd to postcopy
>
From: Prasad Pandit
Refactor ram_save_target_page legacy and multifd
functions into one. Other than simplifying it,
it avoids reinitialization of the 'migration_ops'
object, when migration moves from multifd to postcopy
phase.
Signed-off-by: Prasad Pandit
---
migration/ram.c | 54 +
