This is v6 patchset of modified 'migrate' and 'migrate-incoming' QAPI design for upstream review.
Would like to thank all the maintainers that actively participated in the v5 patchset discussion and gave insightful suggestions to improve the patches. Link to previous upstream community patchset links: v1: https://lists.gnu.org/archive/html/qemu-devel/2022-12/msg04339.html v2: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg02106.html v3: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg02473.html v4: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg03064.html v5: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg04845.html v5 -> v6 changelog: ------------------- - Most changes on the QAPI side, i.e. Patch 1 and Patch 6. - Formatting, improvemnt around migration qapi documentation. - Resolved build issue while building Qemu with compiler as Clang. - Restructured migration unit tests due to recent change aca0406 (tests/qtest: replace wait_command() with qtest......) Abstract: --------- Current QAPI 'migrate' command design (for initiating a migration stream) contains information regarding different migrate transport mechanism (tcp / unix / exec), dest-host IP address, and binding port number in form of a string. Thus the design does seem to have some design issues. Some of the issues, stated below are: 1. Use of string URIs is a data encoding scheme within a data encoding scheme. QEMU code should directly be able to work with the results from QAPI, without resorting to do a second level of parsing (eg. socket_parse()). 2. For features / parameters related to migration, the migration tunables needs to be defined and updated upfront. For example, 'migrate-set-capability' and 'migrate-set-parameter' is required to enable multifd capability and multifd-number of channels respectively. Instead, 'Multifd-channels' can directly be represented as a single additional parameter to 'migrate' QAPI. 'migrate-set-capability' and 'migrate-set-parameter' commands could be used for runtime tunables that need setting after migration has already started. The current patchset focuses on solving the first problem of multi-level encoding of URIs. The patch defines 'migrate' command as a QAPI discriminated union for the various transport backends (like socket, exec and rdma), and on basis of transport backends, different migration parameters are defined. (uri) string --> (channel) Channel-type Transport-type Migration parameters based on transport type ------------------------------------------------------------------------------ Het Gala (9): migration: introduced 'MigrateAddress' in QAPI for migration wire protocol. migration: convert uri parameter into 'MigrateAddress' struct migration: convert socket backend to accept MigrateAddress struct migration: convert rdma backend to accept MigrateAddress struct migration: convert exec backend to accept MigrateAddress struct. migration: modified migration QAPIs to accept 'channels' argument for migration migration: modify migration_channels_and_uri_compatible() to incorporate newer migration QAPI syntax migration: Introduced MigrateChannelList struct to migration code flow. migration: adding test case for modified QAPI syntax migration/exec.c | 72 +++++++++---- migration/exec.h | 8 +- migration/migration-hmp-cmds.c | 16 ++- migration/migration.c | 182 ++++++++++++++++++++++++++------- migration/rdma.c | 34 +++--- migration/rdma.h | 6 +- migration/socket.c | 39 ++----- migration/socket.h | 7 +- qapi/migration.json | 154 +++++++++++++++++++++++++++- softmmu/vl.c | 2 +- tests/qtest/migration-test.c | 45 ++++++++ 11 files changed, 439 insertions(+), 126 deletions(-) -- 2.22.3
