aboutsummaryrefslogtreecommitdiff
path: root/hw/acpi/ghes.c
diff options
context:
space:
mode:
authorFabiano Rosas <farosas@suse.de>2024-02-06 18:51:17 -0300
committerPeter Xu <peterx@redhat.com>2024-02-07 09:53:18 +0800
commit2576ae488ef9aa692486157df7d8b410919cd219 (patch)
treeca8bd9a47baa31389bd857a3bf1dfb9d932c53d1 /hw/acpi/ghes.c
parentdd904bc13f2af0c605c3fe72f118ea4e27a6610c (diff)
downloadqemu-2576ae488ef9aa692486157df7d8b410919cd219.zip
qemu-2576ae488ef9aa692486157df7d8b410919cd219.tar.gz
qemu-2576ae488ef9aa692486157df7d8b410919cd219.tar.bz2
migration/multifd: Unify multifd and TLS connection paths
During multifd channel creation (multifd_send_new_channel_async) when TLS is enabled, the multifd_channel_connect function is called twice, once to create the TLS handshake thread and another time after the asynchrounous TLS handshake has finished. This creates a slightly confusing call stack where multifd_channel_connect() is called more times than the number of channels. It also splits error handling between the two callers of multifd_channel_connect() causing some code duplication. Lastly, it gets in the way of having a single point to determine whether all channel creation tasks have been initiated. Refactor the code to move the reentrancy one level up at the multifd_new_send_channel_async() level, de-duplicating the error handling and allowing for the next patch to introduce a synchronization point common to all the multifd channel creation, regardless of TLS. Note that the previous code would never fail once p->c had been set. This patch changes this assumption, which affects refcounting, so add comments around object_unref to explain the situation. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240206215118.6171-6-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
Diffstat (limited to 'hw/acpi/ghes.c')
0 files changed, 0 insertions, 0 deletions