Hi Daniel, On 2025-08-01 18:02, Daniel P. Berrangé wrote: > This is a followup to previously merged patches that claimed to > workaround the gnutls bug impacting migration, but in fact were > essentially non-functional. Juraj Marcin pointed this out, and > this new patch tweaks the workaround to make it actually do > something useful. > > Daniel P. Berrangé (2): > migration: simplify error reporting after channel read > migration: fix workaround for gnutls thread safety > > crypto/tlssession.c | 16 ---------------- > migration/qemu-file.c | 22 +++++++++++++++++----- > 2 files changed, 17 insertions(+), 21 deletions(-) >
thanks for finding a fix for the workaround. I have tested it and it resolves the issue. However, it significantly slows down migration, even with the workaround disabled (and thus no locking). When benchmarking, I used the fixed version of GNUTLS, VM with 20GB of RAM which were fully written to before starting a normal migration with no workload during the migration. Test cases: [1]: before this patchset [2]: with this patchset applied and GNUTLS workaround enabled [2]: with this patchset applied and GNUTLS workaround disabled | Total time | Throughput | Transfered bytes | --+------------+------------+------------------+ 1 | 31 192 ms | 5450 mpbs | 21 230 973 763 | 2 | 74 147 ms | 2291 mbps | 21 232 849 066 | 3 | 72 426 ms | 2343 mbps | 21 215 009 392 | (data reported by query-migrate QMP command after migration completion) Therefore, this workaround can be used in environments where we cannot use the fixed version of GNUTLS library, but I think it would be better use polling only if locking is actually used, so the performance with the proper GNUTLS fix is not hindered. Maybe yielding/waiting inside tlssession.c before actually locking? Best regards, Juraj Marcin
