[PATCH 00/17] migration: Add new migration channel connect and TLS upgrade APIs

Avihai Horon posted 17 patches 10 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20240125162528.7552-1-avihaih@nvidia.com
Maintainers: Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>
migration/channel.h      |  30 +++++++--
migration/migration.h    |   5 ++
migration/multifd.h      |   3 +
migration/postcopy-ram.h |   2 +-
migration/tls.h          |  30 +++++++--
migration/channel.c      | 106 +++++++++++++++++++++++++----
migration/exec.c         |   2 +-
migration/fd.c           |   2 +-
migration/file.c         |   2 +-
migration/migration.c    |  47 ++++++++-----
migration/multifd.c      | 142 +++++++++++----------------------------
migration/postcopy-ram.c | 111 +++++++++++-------------------
migration/ram.c          |   7 ++
migration/socket.c       |   2 +-
migration/tls.c          |  94 +++++++++++++++++---------
migration/trace-events   |  16 ++---
16 files changed, 344 insertions(+), 257 deletions(-)
[PATCH 00/17] migration: Add new migration channel connect and TLS upgrade APIs
Posted by Avihai Horon 10 months ago
Hello,

Today there are several types of migration channels that can be used
during migration: main migration channel, multifd channels and postcopy
preempt channel. Each channel type has its own code to connect and to
TLS upgrade itself when needed. There is no unified API for these tasks
and it makes the code a bit unclear and cumbersome.

This series aims to solve this by introducing two new APIs for the above
tasks that will replace the existing code.

The first one is an API to TLS upgrade migration channels. A new
function, migration_tls_channel_connect(), is introduced and is used by
main migration, multifd and postcopy preempt channels.

The second one is an API to connect migration channels. A new function,
migration_channel_connect(), is introduced and is used by all migration
channels other than main migration channel, i.e., multifd and postcopy
preempt channels. The reason it's not used by main migration channel is
because the main channel is a bit special and has different flows, and I
didn't see a smooth way to include it.

Patch breakdown:
1-5: Some fixes and cleanups.
6-12: Add new migration channel TLS upgrade API.
13-17: Add new migration channel connect API.

Thanks for reviewing.

Avihai Horon (17):
  migration: Fix logic of channels and transport compatibility check
  migration: Move local_err check in migration_ioc_process_incoming()
  migration: Rename default_channel to main_channel
  migration/multifd: Set p->running = true in the right place
  migration/multifd: Wait for multifd channels creation before
    proceeding
  migration/tls: Rename main migration channel TLS functions
  migration/tls: Add new migration channel TLS upgrade API
  migration: Use the new TLS upgrade API for main channel
  migration/multifd: Use the new TLS upgrade API for multifd channels
  migration/postcopy: Use the new TLS upgrade API for preempt channel
  migration/tls: Make migration_tls_client_create() static
  migration/multifd: Consolidate TLS/non-TLS multifd channel error flow
  migration: Store MigrationAddress in MigrationState
  migration: Rename migration_channel_connect()
  migration: Add new migration channel connect API
  migration/multifd: Use the new migration channel connect API for
    multifd
  migration/postcopy: Use the new migration channel connect API for
    postcopy preempt

 migration/channel.h      |  30 +++++++--
 migration/migration.h    |   5 ++
 migration/multifd.h      |   3 +
 migration/postcopy-ram.h |   2 +-
 migration/tls.h          |  30 +++++++--
 migration/channel.c      | 106 +++++++++++++++++++++++++----
 migration/exec.c         |   2 +-
 migration/fd.c           |   2 +-
 migration/file.c         |   2 +-
 migration/migration.c    |  47 ++++++++-----
 migration/multifd.c      | 142 +++++++++++----------------------------
 migration/postcopy-ram.c | 111 +++++++++++-------------------
 migration/ram.c          |   7 ++
 migration/socket.c       |   2 +-
 migration/tls.c          |  94 +++++++++++++++++---------
 migration/trace-events   |  16 ++---
 16 files changed, 344 insertions(+), 257 deletions(-)

-- 
2.26.3
Re: [PATCH 00/17] migration: Add new migration channel connect and TLS upgrade APIs
Posted by Peter Xu 9 months, 3 weeks ago
On Thu, Jan 25, 2024 at 06:25:11PM +0200, Avihai Horon wrote:
> Hello,
> 
> Today there are several types of migration channels that can be used
> during migration: main migration channel, multifd channels and postcopy
> preempt channel. Each channel type has its own code to connect and to
> TLS upgrade itself when needed. There is no unified API for these tasks
> and it makes the code a bit unclear and cumbersome.
> 
> This series aims to solve this by introducing two new APIs for the above
> tasks that will replace the existing code.
> 
> The first one is an API to TLS upgrade migration channels. A new
> function, migration_tls_channel_connect(), is introduced and is used by
> main migration, multifd and postcopy preempt channels.
> 
> The second one is an API to connect migration channels. A new function,
> migration_channel_connect(), is introduced and is used by all migration
> channels other than main migration channel, i.e., multifd and postcopy
> preempt channels. The reason it's not used by main migration channel is
> because the main channel is a bit special and has different flows, and I
> didn't see a smooth way to include it.
> 
> Patch breakdown:
> 1-5: Some fixes and cleanups.
> 6-12: Add new migration channel TLS upgrade API.
> 13-17: Add new migration channel connect API.

Hi, Avihai,

I am queuing patch 1 as it does look like a real bug to fix asap.  I'll
copy stable for that one.  For such patches, feel free to post separately
next time if you think I should merge earlier than the rest.

For the thread race issue: I believe it should be fully covered by
Fabiano's series, at least that's the plan.  Let me know if there's still
something missing.

For the rest: I didn't closely check, but obviously many of the changes
will not apply after applying Fabiano's fix on the thread races.  If you
have anything that still think worth merging, please rebase to that (or
wait for my pull; it should happen this week).

Thanks,

-- 
Peter Xu
Re: [PATCH 00/17] migration: Add new migration channel connect and TLS upgrade APIs
Posted by Avihai Horon 9 months, 3 weeks ago
On 06/02/2024 12:04, Peter Xu wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, Jan 25, 2024 at 06:25:11PM +0200, Avihai Horon wrote:
>> Hello,
>>
>> Today there are several types of migration channels that can be used
>> during migration: main migration channel, multifd channels and postcopy
>> preempt channel. Each channel type has its own code to connect and to
>> TLS upgrade itself when needed. There is no unified API for these tasks
>> and it makes the code a bit unclear and cumbersome.
>>
>> This series aims to solve this by introducing two new APIs for the above
>> tasks that will replace the existing code.
>>
>> The first one is an API to TLS upgrade migration channels. A new
>> function, migration_tls_channel_connect(), is introduced and is used by
>> main migration, multifd and postcopy preempt channels.
>>
>> The second one is an API to connect migration channels. A new function,
>> migration_channel_connect(), is introduced and is used by all migration
>> channels other than main migration channel, i.e., multifd and postcopy
>> preempt channels. The reason it's not used by main migration channel is
>> because the main channel is a bit special and has different flows, and I
>> didn't see a smooth way to include it.
>>
>> Patch breakdown:
>> 1-5: Some fixes and cleanups.
>> 6-12: Add new migration channel TLS upgrade API.
>> 13-17: Add new migration channel connect API.
> Hi, Avihai,
>
> I am queuing patch 1 as it does look like a real bug to fix asap.  I'll
> copy stable for that one.  For such patches, feel free to post separately
> next time if you think I should merge earlier than the rest.

Sure, will do so next time.

>
> For the thread race issue: I believe it should be fully covered by
> Fabiano's series, at least that's the plan.  Let me know if there's still
> something missing.

Yep, Fabiano's series seems to have taken care of everything.

>
> For the rest: I didn't closely check, but obviously many of the changes
> will not apply after applying Fabiano's fix on the thread races.  If you
> have anything that still think worth merging, please rebase to that (or
> wait for my pull; it should happen this week).

Sure, thanks.