qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 21/28] migration: setup ramstate for resume


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v6 21/28] migration: setup ramstate for resume
Date: Wed, 14 Feb 2018 12:20:00 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Tue, Feb 13, 2018 at 06:17:51PM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (address@hidden) wrote:
> > After we updated the dirty bitmaps of ramblocks, we also need to update
> > the critical fields in RAMState to make sure it is ready for a resume.
> > 
> > Signed-off-by: Peter Xu <address@hidden>
> > ---
> >  migration/ram.c        | 40 +++++++++++++++++++++++++++++++++++++++-
> >  migration/trace-events |  1 +
> >  2 files changed, 40 insertions(+), 1 deletion(-)
> > 
> > diff --git a/migration/ram.c b/migration/ram.c
> > index a2a4b05d5c..d275875f54 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -2250,6 +2250,36 @@ static int ram_init_all(RAMState **rsp)
> >      return 0;
> >  }
> >  
> > +static void ram_state_resume_prepare(RAMState *rs, QEMUFile *out)
> > +{
> > +    RAMBlock *block;
> > +    long pages = 0;
> > +
> > +    /*
> > +     * Postcopy is not using xbzrle/compression, so no need for that.
> > +     * Also, since source are already halted, we don't need to care
> > +     * about dirty page logging as well.
> > +     */
> > +
> > +    RAMBLOCK_FOREACH(block) {
> > +        pages += bitmap_count_one(block->bmap,
> > +                                  block->used_length >> TARGET_PAGE_BITS);
> > +    }
> > +
> > +    /* This may not be aligned with current bitmaps. Recalculate. */
> > +    rs->migration_dirty_pages = pages;
> 
> migration_dirty_pages is uint64_t - so we should probably do the cast
> above and keep 'pages' as uint64_t.

Sure.

> 
> > +    rs->last_seen_block = NULL;
> > +    rs->last_sent_block = NULL;
> > +    rs->last_page = 0;
> > +    rs->last_version = ram_list.version;
> 
> Do you need to explicitly set
>        rs->ram_bulk_stage = false;
> 
> if the failure happened just after the start of postcopy and no
> requested pages had been sent, I think it might still  be set?

Could you elaborate what would go wrong even if it's still set?

Thanks,

-- 
Peter Xu



reply via email to

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