Dongli Zhang <[email protected]> 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 <[email protected]>
> ---
> 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:
