qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Het Gala <het.gala@nutanix.com>
To: qemu-devel@nongnu.org
Cc: prerna.saxena@nutanix.com, quintela@redhat.com,
	dgilbert@redhat.com, pbonzini@redhat.com, berrange@redhat.com,
	armbru@redhat.com, eblake@redhat.com, manish.mishra@nutanix.com,
	aravind.retnakaran@nutanix.com
Subject: Re: [PATCH v10 00/10] migration: Modify 'migrate' and 'migrate-incoming' QAPI commands for migration
Date: Thu, 3 Aug 2023 11:13:05 +0530	[thread overview]
Message-ID: <a81add8b-f08b-6589-e9f5-779a4a7bd63f@nutanix.com> (raw)
In-Reply-To: <30cffa41-3e39-205f-5119-d84d6303f58c@nutanix.com>

Hi,

A gentle reminder for Juan and other migration maintainers for the 
review of this patchset series if any changes are required or give to 
queue them. There are more patchset series coming after this. As 
discussed earlier, we have broken down it into 4 different patchset 
series. This is just Part1 of the 4 patchset series. Ultimate goal is to 
'introduce multiple interface support on top of existing multifd 
capability'.

On 27/07/23 4:59 pm, Het Gala wrote:
> This is just a ping for Juan and other migration maintainers, if it's 
> possible to have a look at the migration patches for new QAPI design 
> and suggest some review comments if any.
>
> Update till now : Have got acked-by label from Markus for the new 
> migrate QAPI design, and reviewd-by label from Daniel on the QAPI 
> implementation side patches.
>
> On 26/07/23 7:48 pm, Het Gala wrote:
>> This is v10 patchset of modified 'migrate' and 'migrate-incoming' 
>> QAPI design
>> for upstream review.
>>
>> Would like to thank all the maintainers that actively participated in 
>> the v9
>> 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
>> v6: https://lists.gnu.org/archive/html/qemu-devel/2023-06/msg01251.html
>> v7: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02027.html
>> v8: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02770.html
>> v9: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg04216.html
>>
>> v9 -> v10 changelog:
>> -------------------
>> - Patch6 : Added extra checks for migration arguments.
>> - Patch8 : Added checks for 'uri' and 'channels' both not present.
>> - Patch9 : Missed adding hmp_handle_error call to print error messages.
>> 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 (10):
>>    migration: New QAPI type 'MigrateAddress'
>>    migration: convert migration 'uri' into 'MigrateAddress'
>>    migration: convert socket backend to accept MigrateAddress
>>    migration: convert rdma backend to accept MigrateAddress
>>    migration: convert exec backend to accept MigrateAddress.
>>    migration: New migrate and migrate-incoming argument 'channels'
>>    migration: modify migration_channels_and_uri_compatible() for new 
>> QAPI
>>      syntax
>>    migration: Implement MigrateChannelList to qmp migration flow.
>>    migration: Implement MigrateChannelList to hmp migration flow.
>>    migration: modify test_multifd_tcp_none() to use new QAPI syntax.
>>
>>   migration/exec.c               |  72 +++++++++----
>>   migration/exec.h               |   8 +-
>>   migration/migration-hmp-cmds.c |  17 ++-
>>   migration/migration.c          | 190 ++++++++++++++++++++++++++-------
>>   migration/migration.h          |   3 +-
>>   migration/rdma.c               |  34 +++---
>>   migration/rdma.h               |   6 +-
>>   migration/socket.c             |  39 ++-----
>>   migration/socket.h             |   7 +-
>>   qapi/migration.json            | 150 +++++++++++++++++++++++++-
>>   softmmu/vl.c                   |   2 +-
>>   tests/qtest/migration-test.c   |   7 +-
>>   12 files changed, 409 insertions(+), 126 deletions(-)
> Regards,
> Het Gala
Regards,
Het Gala


  reply	other threads:[~2023-08-03  5:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26 14:18 [PATCH v10 00/10] migration: Modify 'migrate' and 'migrate-incoming' QAPI commands for migration Het Gala
2023-07-26 14:18 ` [PATCH v10 01/10] migration: New QAPI type 'MigrateAddress' Het Gala
2023-07-26 14:18 ` [PATCH v10 02/10] migration: convert migration 'uri' into 'MigrateAddress' Het Gala
2023-07-26 14:18 ` [PATCH v10 03/10] migration: convert socket backend to accept MigrateAddress Het Gala
2023-07-26 14:18 ` [PATCH v10 04/10] migration: convert rdma " Het Gala
2023-07-26 14:18 ` [PATCH v10 05/10] migration: convert exec " Het Gala
2023-07-26 14:18 ` [PATCH v10 06/10] migration: New migrate and migrate-incoming argument 'channels' Het Gala
2023-07-26 14:53   ` Daniel P. Berrangé
2023-07-26 14:18 ` [PATCH v10 07/10] migration: modify migration_channels_and_uri_compatible() for new QAPI syntax Het Gala
2023-07-26 14:18 ` [PATCH v10 08/10] migration: Implement MigrateChannelList to qmp migration flow Het Gala
2023-07-26 14:54   ` Daniel P. Berrangé
2023-07-26 14:18 ` [PATCH v10 09/10] migration: Implement MigrateChannelList to hmp " Het Gala
2023-07-26 14:55   ` Daniel P. Berrangé
2023-07-26 16:38     ` Het Gala
2023-07-26 16:41       ` Daniel P. Berrangé
2023-07-26 17:07         ` Het Gala
2023-07-26 14:18 ` [PATCH v10 10/10] migration: modify test_multifd_tcp_none() to use new QAPI syntax Het Gala
2023-07-27 11:29 ` [PATCH v10 00/10] migration: Modify 'migrate' and 'migrate-incoming' QAPI commands for migration Het Gala
2023-08-03  5:43   ` Het Gala [this message]
2023-08-21  6:13     ` Het Gala
2023-08-21 16:36       ` Peter Xu
2023-09-05 13:22       ` Fabiano Rosas
2023-10-04  5:01         ` Het Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a81add8b-f08b-6589-e9f5-779a4a7bd63f@nutanix.com \
    --to=het.gala@nutanix.com \
    --cc=aravind.retnakaran@nutanix.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=manish.mishra@nutanix.com \
    --cc=pbonzini@redhat.com \
    --cc=prerna.saxena@nutanix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).