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

[Dr. David Alan Gilbert]

* Peter Maydell (address@hidden) wrote:
> On Thu, 21 Mar 2019 at 15:32, Catherine Ho <address@hidden> wrote:
> > So in igore-shared case, dtb is not required here ?
> 
> Can you explain what the "ignore-shared" case is?

It's a migration capability added recently by Yury Kotov,
which as you say below, skips migration of shared ram blocks.
The definition of 'shared' is that the RAMBlock rb->flags has
RAM_SHARED set, and that normally corresponds to when we call
mmap with MAP_SHARED.  The user visible version of that is
normally if you set up memory with a hostmem backend it has a 
'share' property.  So 'ignore-shared' corresponds to 'share=on'
on the memory backend.

> 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.

Dave

> > Maybe I could add a flag in struct Rom to set it when the rom is created by
> > rom_add_blob_fixed_as()? And in rom_reset, just bypass this rom when
> > in_incoming_migration && ignore_shared
> 
> No, I think this is wrong -- the particular function used
> to create the rom blob data should not affect how we are
> treating it.
> 
> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK