Re: [Qemu-devel] [PATCH] migration: avoid copying ignore-shared ramblock when in incoming migration

[Catherine Ho]

Hi all, thanks for the comments, I am digging into another potential
error in the
ignore-shared live migration. After that, I will send out the v2 asap
B.R.
Catherine


On Mon, 25 Mar 2019 at 11:39, Peter Xu <address@hidden> wrote:
>
> On Fri, Mar 22, 2019 at 10:12:11AM +0000, Dr. David Alan Gilbert wrote:
>
> [...]
>
> > > In general, when we reset the system, we want to bring it
> > > back to exactly the state that it was in when QEMU was
> > > first started. That means we need to reload all the rom blob
> > > data into memory (because the guest might have modified
> > > that memory while it was running).
> > >
> > > If I understand correctly from other threads, the idea is
> > > that some of the RAM is shared between source and destination
> > > so it does not need to be manually copied during migration.
> > > If that is correct, then perhaps the right thing is that
> > > in the rom_reset code:
> > >  * if this rom blob is being loaded into a "shared" ram block
> > >  * and this reset is happening specifically before an
> > >    inbound migration
> > >  * then skip loading the rom blob data
> > >
> > > ?
> > >
> > > I don't know the right way to determine either the "is this
> > > a shared ram area" or "is this the reset prior to inbound
> > > migration", but perhaps you can fill that in.
> >
> > Right, so in Catherine's patch there's a simple in_incoming_migration
> > and checking ramblock_is_ignored;  it might be better to use the
> > qemu_ram_is_shared() call and I wonder if we can just check for being in
> > RUN_STATE_INMIGRATE - if that's early enough.
>
> Yes I feel like runstate_check(RUN_STATE_INMIGRATE) should be enough
> to replace the new variable.  And I'm even thinking whether we need to
> check qemu_ram_is_shared() at all... if rom_reset() simply refills the
> ROM data into the RAMs, then IIUC that operation could be skipped for
> all incoming migrations because all those ROM data (no matter they are
> filled into shared RAM or not) should already have been filled on the
> source side and:
>
> - if the ROM data's RAMBlock is shared backend, the latest data should
>   already been there on the shared backend files, or,
>
> - if the ROM data's RAMBlock is not shared backend, they'll eventually
>   be migrated to the destination later on after this rom_reset() on
>   destination by the general RAM migration code.
>
> Regards,
>
> --
> Peter Xu