From: Yury Kotov <yury-kotov@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-kotov@yandex-team.ru>
Message-Id: <20190215174548.2630-3-yury-kotov@yandex-team.ru>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
 migration/migration.c | 14 ++++++++++++++
 migration/migration.h |  1 +
 qapi/migration.json   |  5 ++++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index e44f77af02..4ff195c901 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -989,6 +989,11 @@ static bool migrate_caps_check(bool *cap_list,
             error_setg(errp, "Postcopy is not supported");
             return false;
         }
+
+        if (cap_list[MIGRATION_CAPABILITY_X_IGNORE_SHARED]) {
+            error_setg(errp, "Postcopy is not compatible with ignore-shared");
+            return false;
+        }
     }
 
     return true;
@@ -2068,6 +2073,15 @@ bool migrate_dirty_bitmaps(void)
     return s->enabled_capabilities[MIGRATION_CAPABILITY_DIRTY_BITMAPS];
 }
 
+bool migrate_ignore_shared(void)
+{
+    MigrationState *s;
+
+    s = migrate_get_current();
+
+    return s->enabled_capabilities[MIGRATION_CAPABILITY_X_IGNORE_SHARED];
+}
+
 bool migrate_use_events(void)
 {
     MigrationState *s;
diff --git a/migration/migration.h b/migration/migration.h
index c99154dea2..443051adb0 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -265,6 +265,7 @@ bool migrate_release_ram(void);
 bool migrate_postcopy_ram(void);
 bool migrate_zero_blocks(void);
 bool migrate_dirty_bitmaps(void);
+bool migrate_ignore_shared(void);
 
 bool migrate_auto_converge(void);
 bool migrate_use_multifd(void);
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)
+#
 # 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:
-- 
2.20.1

"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> writes:

> From: Yury Kotov <yury-kotov@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-kotov@yandex-team.ru>
> Message-Id: <20190215174548.2630-3-yury-kotov@yandex-team.ru>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: Dr. David Alan Gilbert <dgilbert@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"?

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

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

> +#
>  # 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:

Markus Armbruster <armbru@redhat.com> wrote:
> "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> writes:
>
>> From: Yury Kotov <yury-kotov@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-kotov@yandex-team.ru>
>> Message-Id: <20190215174548.2630-3-yury-kotov@yandex-team.ru>
>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>> Signed-off-by: Dr. David Alan Gilbert <dgilbert@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"?
>
> Specifically: say you have an ivshmem-plain device.  Is its shared
> memory migrated?
>
> No objection to the pull request; if documentation improvements are
> necessary, we can do them in a follow-up patch.

They migrate to the same host to update the running qemu.
What they are trying to do is to share the guest memory so they don't
have to copy that memory (remember that they are inside the same host).

It is up to you to decide if that is a great idea or "abuse" the
interface (Anyways the change is small enough).

Later, Juan.

Juan Quintela <quintela@redhat.com> writes:

> Markus Armbruster <armbru@redhat.com> wrote:
>> "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> writes:
>>
>>> From: Yury Kotov <yury-kotov@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-kotov@yandex-team.ru>
>>> Message-Id: <20190215174548.2630-3-yury-kotov@yandex-team.ru>
>>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>> Signed-off-by: Dr. David Alan Gilbert <dgilbert@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"?
>>
>> Specifically: say you have an ivshmem-plain device.  Is its shared
>> memory migrated?
>>
>> No objection to the pull request; if documentation improvements are
>> necessary, we can do them in a follow-up patch.
>
> They migrate to the same host to update the running qemu.
> What they are trying to do is to share the guest memory so they don't
> have to copy that memory (remember that they are inside the same host).
>
> It is up to you to decide if that is a great idea or "abuse" the
> interface (Anyways the change is small enough).

I'm not passing judgement on the feature, only on the doc comment: it
uses the term "shared memory" without defining it!  It really should,
because "shared memory" is commonly used in ways that do not apply here,
such as "the memory shared with other processes" (this includes shared
objects), "System V shared memory", and possibly more.

Please address this in a follow-up patch.

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