* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert (git)" <dgilb...@redhat.com> writes:
>
> > From: Yury Kotov <yury-ko...@yandex-team.ru>
> >
> > 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 <yury-ko...@yandex-team.ru>
> > Message-Id: <20190215174548.2630-3-yury-ko...@yandex-team.ru>
> > Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > ---
> [...]
> > 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 / dgilb...@redhat.com / Manchester, UK
