On Thu, Feb 06, 2025 at 02:32:12PM -0300, Fabiano Rosas wrote: > > In any case we'd still need some kind of a compatibility behavior for > > the TLS bit stream emitted by older QEMU versions (which is always > > improperly terminated). > > > > There is no compat issue. For <= 9.2, QEMU is still doing an extra > multifd_send_sync_main(), which results in an extra MULTIFD_FLAG_SYNC on > the destination and it gets stuck waiting for the > RAM_SAVE_FLAG_MULTIFD_FLUSH that never comes. Therefore the src always > closes the connection before dst reaches the extra recv(). > > I test migration both ways with 2 previous QEMU versions and the > gnutls_bye() series passes all tests. I also put an assert at > tlssession.c and never triggers for GNUTLS_E_PREMATURE_TERMINATION. The > MULTIFD_FLAG_EOS should behave the same.
Which are the versions you tried? As only 9.1 and 9.2 has 637280aeb2, so I wonder if the same issue would hit too with 9.0 or older. I'd confess I feel unreliable relying on the side effect of 637280aeb2, because fundamentally it works based on the fact that multifd threads need to be kicked out by the main load thread SYNC event on dest QEMU to avoid the readv() from going wrong. What I'm not sure here is, is it sheer luck that the main channel SYNC will always arrive _before_ pre-mature terminations of the multifd channels? It sounds like it could also happen when the multifd channels got its pre-mature termination early, before the main thread got the SYNC. Maybe we still need a compat property at the end.. -- Peter Xu
