riscv/qemu - qemu - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Fabiano Rosas	5a26b76b4a	migration: Cleanup TLS handshake hostname passing The TLS hostname is doing a tour around the world just to be cached into s->hostname. We're already abusing MigrationState by doing that, so incorporate the s->hostname into migration_tls_hostname() and stop passing the string around. The old route was roughly: -transport code (socket.c, fd.c, etc): if (SOCKET_ADDRESS_TYPE_INET) hostname = saddr->u.inet.host else hostname = NULL migration_channel_connect(..., hostname) s->hostname = hostname; migration_tls_client_create(..., hostname) if (migrate_tls_hostname()) qio_channel_tls_new_client(migrate_tls_hostname()) else qio_channel_tls_new_client(hostname) -postcopy_preempt_setup: postcopy_preempt_send_channel_new migration_tls_client_create(..., s->hostname) New route is: -socket.c only: if SOCKET_ADDRESS_TYPE_INET s->hostname = saddr->u.inet.host migration_channel_connect() migration_tls_client_create() qio_channel_tls_new_client(migrate_tls_hostname()) -postcopy_preempt_setup: postcopy_preempt_send_channel_new migration_tls_client_create() qio_channel_tls_new_client(migrate_tls_hostname()) Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Prasad Pandit <pjp@fedoraproject.org> Link: https://lore.kernel.org/qemu-devel/20260123141656.6765-5-farosas@suse.de Signed-off-by: Fabiano Rosas <farosas@suse.de>	7 months ago
manish.mishra	6720c2b327	migration: check magic value for deciding the mapping of channels Current logic assumes that channel connections on the destination side are always established in the same order as the source and the first one will always be the main channel followed by the multifid or post-copy preemption channel. This may not be always true, as even if a channel has a connection established on the source side it can be in the pending state on the destination side and a newer connection can be established first. Basically causing out of order mapping of channels on the destination side. Currently, all channels except post-copy preempt send a magic number, this patch uses that magic number to decide the type of channel. This logic is applicable only for precopy(multifd) live migration, as mentioned, the post-copy preempt channel does not send any magic number. Also, tls live migrations already does tls handshake before creating other channels, so this issue is not possible with tls, hence this logic is avoided for tls live migrations. This patch uses read peek to check the magic number of channels so that current data/control stream management remains un-effected. Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: manish.mishra <manish.mishra@nutanix.com> Signed-off-by: Juan Quintela <quintela@redhat.com>	4 years ago
Dr. David Alan Gilbert	688a3dcba9	migration: Route errors down through migration_channel_connect Route async errors (especially from sockets) down through migration_channel_connect and on to migrate_fd_connect where they can be cleaned up. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>	9 years ago
Juan Quintela	543147116e	migration: Remove MigrationState from migration_channel_incomming() All callers were calling migrate_get_current(), so do it inside the function. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>	9 years ago
Juan Quintela	dd4339c540	migration: Split migration/channel.c for channel operations Create an include for its exported functions. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> --- Add proper header	9 years ago