Re: [PATCH v7 3/5] migration: Add zero-copy parameter for QMP/HMP for Linux

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jan 06, 2022 at 07:13:40PM -0300, Leonardo Bras wrote:
> Add property that allows zero-copy migration of memory pages,
> and also includes a helper function migrate_use_zero_copy() to check
> if it's enabled.
> 
> No code is introduced to actually do the migration, but it allow
> future implementations to enable/disable this feature.
> 
> On non-Linux builds this parameter is compiled-out.
> 
> Signed-off-by: Leonardo Bras <leobras@redhat.com>
> ---
>  qapi/migration.json   | 24 ++++++++++++++++++++++++
>  migration/migration.h |  5 +++++
>  migration/migration.c | 32 ++++++++++++++++++++++++++++++++
>  migration/socket.c    |  5 +++++
>  monitor/hmp-cmds.c    |  6 ++++++
>  5 files changed, 72 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

> 
> diff --git a/qapi/migration.json b/qapi/migration.json
> index bbfd48cf0b..2e62ea6ebd 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -730,6 +730,13 @@
>  #                      will consume more CPU.
>  #                      Defaults to 1. (Since 5.0)
>  #
> +# @zero-copy: Controls behavior on sending memory pages on migration.
> +#             When true, enables a zero-copy mechanism for sending memory
> +#             pages, if host supports it.
> +#             Requires that QEMU be permitted to use locked memory for guest
> +#             RAM pages.
> +#             Defaults to false. (Since 7.0)
> +#
>  # @block-bitmap-mapping: Maps block nodes and bitmaps on them to
>  #                        aliases for the purpose of dirty bitmap migration.  Such
>  #                        aliases may for example be the corresponding names on the
> @@ -769,6 +776,7 @@
>             'xbzrle-cache-size', 'max-postcopy-bandwidth',
>             'max-cpu-throttle', 'multifd-compression',
>             'multifd-zlib-level' ,'multifd-zstd-level',
> +           { 'name': 'zero-copy', 'if' : 'CONFIG_LINUX'},
>             'block-bitmap-mapping' ] }
>  
>  ##
> @@ -895,6 +903,13 @@
>  #                      will consume more CPU.
>  #                      Defaults to 1. (Since 5.0)
>  #
> +# @zero-copy: Controls behavior on sending memory pages on migration.
> +#             When true, enables a zero-copy mechanism for sending memory
> +#             pages, if host supports it.
> +#             Requires that QEMU be permitted to use locked memory for guest
> +#             RAM pages.
> +#             Defaults to false. (Since 7.0)
> +#
>  # @block-bitmap-mapping: Maps block nodes and bitmaps on them to
>  #                        aliases for the purpose of dirty bitmap migration.  Such
>  #                        aliases may for example be the corresponding names on the
> @@ -949,6 +964,7 @@
>              '*multifd-compression': 'MultiFDCompression',
>              '*multifd-zlib-level': 'uint8',
>              '*multifd-zstd-level': 'uint8',
> +            '*zero-copy': { 'type': 'bool', 'if': 'CONFIG_LINUX' },
>              '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }

The current zerocopy impl is for the send path.

Do you expect we might get zerocopy in the receive path
later ?

If so then either call this 'send-zero-copy', or change it
from a bool to an enum taking '["send", "recv", "both"]'.

I'd probably take the former and just rename it.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|