Re: [PATCH 1/5] migration/qapi: Add memfd migration transport

[Markus Armbruster <armbru@redhat.com>]

Dongli Zhang <dongli.zhang@oracle.com> writes:

> Add a memfd migration transport to the MigrationAddress QAPI schema. The
> new transport has no user-supplied arguments because QEMU creates and
> passes the backing memfd internally.
>
> The initial user is cpr-exec, where the main VM/device migration stream can
> be stored in an inherited memfd instead of an external file.
>
> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
> ---
>  qapi/migration.json | 32 +++++++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index b1eaf7b054..1505c201ca 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -702,9 +702,11 @@
>  # @cpr-exec: The migrate command stops the VM, saves state to the
>  #     migration channel, directly exec's a new version of QEMU on the
>  #     same host, replacing the original process while retaining its
> -#     PID, and loads state from the channel.  Guest RAM is preserved
> -#     in place.  Devices and their pinned pages are also preserved for
> -#     VFIO and IOMMUFD.
> +#     PID, and loads state from the channel.  With the @memfd
> +#     migration transport, QEMU saves VM/device state to an internal
> +#     memfd instead of an external main migration channel.  Guest RAM
> +#     is preserved in place.  Devices and their pinned pages are also
> +#     preserved for VFIO and IOMMUFD.
>  #
>  #     Old QEMU starts new QEMU by exec'ing the command specified by
>  #     the @cpr-exec-command parameter.  The command may be a direct
> @@ -716,6 +718,13 @@
>  #     as a file, that accepts all data before old QEMU exits.
>  #     Otherwise, old QEMU may quietly block writing to the channel.
>  #
> +#     Alternatively, use the @memfd migration transport to save
> +#     VM/device state to an internal memfd inherited by new QEMU.
> +#

Any guidance on when to use @memfd?

> +#     With @memfd, the new QEMU command may include '-incoming memfd:'
> +#     to load the migration stream automatically, or '-incoming defer'
> +#     to load it later with `migrate-incoming`.
> +#

Isn't that the same for any transport?  I.e. old and new QEMU must use a
common transport, and you configure it for the new one with -incoming
right away, or later with migrate-incoming.

>  #     Memory-backend objects must have the share=on attribute, but
>  #     memory-backend-epc is not supported.  The VM must be started
>  #     with the '-machine aux-ram-share=on' option.
> @@ -1309,10 +1318,14 @@
>  #
>  # @file: Direct the migration stream to a file.
>  #
> +# @memfd: Direct the migration stream to an internal memfd.  This
> +#     transport is currently only valid with cpr-exec migration mode.
> +#     (Since 11.2)
> +#
>  # Since: 8.2
>  ##
>  { 'enum': 'MigrationAddressType',
> -  'data': [ 'socket', 'exec', 'rdma', 'file' ] }
> +  'data': [ 'socket', 'exec', 'rdma', 'file', 'memfd' ] }
>  
>  ##
>  # @FileMigrationArgs:
> @@ -1337,6 +1350,14 @@
>  { 'struct': 'MigrationExecCommand',
>    'data': {'args': [ 'str' ] } }
>  
> +##
> +# @MemfdMigrationArgs:
> +#
> +# Since: 11.2
> +##
> +{ 'struct': 'MemfdMigrationArgs',
> +  'data': { } }
> +
>  ##
>  # @MigrationAddress:
>  #
> @@ -1353,7 +1374,8 @@
>      'socket': 'SocketAddress',
>      'exec': 'MigrationExecCommand',
>      'rdma': 'InetSocketAddress',
> -    'file': 'FileMigrationArgs' } }
> +    'file': 'FileMigrationArgs',
> +    'memfd': 'MemfdMigrationArgs' } }

Simpler: omit branch @memfd, no need for struct MemfdMigrationArgs.

>  ##
>  # @MigrationChannelType: