Re: [Qemu-devel] [PULL 05/21] migration: Introduce ignore-shared capability

[Dr. David Alan Gilbert]

* Markus Armbruster (address@hidden) wrote:
> "Dr. David Alan Gilbert (git)" <address@hidden> writes:
> 
> > From: Yury Kotov <address@hidden>
> >
> > We want to use local migration to update QEMU for running guests.
> > In this case we don't need to migrate shared (file backed) RAM.
> > So, add a capability to ignore such blocks during live migration.
> >
> > Signed-off-by: Yury Kotov <address@hidden>
> > Message-Id: <address@hidden>
> > Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > ---
> [...]
> > diff --git a/qapi/migration.json b/qapi/migration.json
> > index 1fd7bbea9b..eab87340b2 100644
> > --- a/qapi/migration.json
> > +++ b/qapi/migration.json
> > @@ -409,13 +409,16 @@
> >  #           devices (and thus take locks) immediately at the end of 
> > migration.
> >  #           (since 3.0)
> >  #
> > +# @x-ignore-shared: If enabled, QEMU will not migrate shared memory (since 
> > 4.0)
> 
> What exactly is considered "shared memory"?

There's an existing property of RAMBlock's called 'shared' and this is
exactly whether that existing property is set; it corresponds to the
'share' property in hostmem, which is a user visible property and
normally maps to whether we have MAP_SHARED.

> Specifically: say you have an ivshmem-plain device.  Is its shared
> memory migrated?

Hmm good question.
So I think it comes down to whether the call to
'memory_region_init_ram_from_fd' has the 'share' flag set, which ends
up setting a RAM_SHARED ram_flag when it's passed to
qemu_ram_alloc_from_fd.

In hw/misc/ivshmem.c I see:


    /* mmap the region and map into the BAR2 */
    memory_region_init_ram_from_fd(&s->server_bar2, OBJECT(s),
                                   "ivshmem.bar2", size, true, fd, &local_err);

and that 'true' is the 'share' flag.

So, yep, it skips that.

> No objection to the pull request; if documentation improvements are
> necessary, we can do them in a follow-up patch.

I wonder how to describe it; since it mapped 1-1 with the 'shared' flag
on hostmem I hadn't thought it needed anything extra; but the ivshmem
case I guess is a special, I wonder what others there are.

Dave

> > +#
> >  # Since: 1.2
> >  ##
> >  { 'enum': 'MigrationCapability',
> >    'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> >             'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> >             'block', 'return-path', 'pause-before-switchover', 'x-multifd',
> > -           'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate' ] }
> > +           'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
> > +           'x-ignore-shared' ] }
> >  
> >  ##
> >  # @MigrationCapabilityStatus:
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK