From: Fabiano Rosas <farosas@suse.de>
To: Michael Tokarev <mjt@tls.msk.ru>,
peterx@redhat.com, Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org
Cc: qemu-stable <qemu-stable@nongnu.org>
Subject: Re: [PULL 26/34] migration/multifd: Join the TLS thread
Date: Thu, 15 Feb 2024 10:24:53 -0300 [thread overview]
Message-ID: <878r3lsvve.fsf@suse.de> (raw)
In-Reply-To: <d3c4506f-0dbd-4171-944d-0aeb040153ad@tls.msk.ru>
Michael Tokarev <mjt@tls.msk.ru> writes:
> 14.02.2024 16:27, Fabiano Rosas :
>> Michael Tokarev <mjt@tls.msk.ru> writes:
> ..>>> This change, which is suggested for -stable, while simple by its own, seems
>>>> to depend on the previous changes in this series, which are not for -stable.
>>>> In particular, whole "Finally recycle all the threads" loop in multifd_send_terminate_threads()
>>>> (to which the join is being added by this change) is moved from elsewhere by
>>>> 12808db3b8 "migration/multifd: Cleanup multifd_save_cleanup()" (patch 24 in
>>>> this same series).
>>>>
>>> We can probably add the missing join right into the previous location of this
>>> loop (before 12808db3b8). I did this in the attached variant for 8.2, is
>>> this correct?
>
> I forgot to attach the patch. It just moves the join from multifd_send_terminate_threads()
> back to multifd_save_cleanup. Attached now.
>
>> It should work. This was originally developed without the rest of the
>> changes on this PR.
>>
>>> And this does not pass even the basic tests, so it's not that simple :)
>>
>> Do you have a log of what failed?
>
> Re-running it again... I haven't even tried to push it somewhere for CI to run,
> I run local `ninja test', which painted some migration tests in red. Here:
>
> 202/844 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test ERROR 70.26s killed by signal 6 SIGABRT
> 330/844 qemu:qtest+qtest-i386 / qtest-i386/migration-test ERROR 85.33s killed by signal 6 SIGABRT
> 454/844 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test ERROR 101.02s killed by signal 6 SIGABRT
>
> Unfortunately I don't see anything interesting in the log:
>
> # starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-463614.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-463614.qmp,id=char0
> -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-8.2, -name target,debug-threads=on -m 150M -serial
> file:/tmp/migration-test-SPJTI2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-SPJTI2/bootsect,format=raw -device
> ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest
> ----------------------------------- stderr -----------------------------------
> ../../build/qemu/8.2/tests/qtest/libqtest.c:204: kill_qemu() detected QEMU death from signal 6 (Aborted)
> (test program exited with status code -6)
>
> Without the attached patch it works.
Ah ok, this is hitting the bug fixed by patch 31. Let's leave patches
26, 27 and 31 out of stable, it would be too risky to backport.
next prev parent reply other threads:[~2024-02-15 13:25 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 3:04 [PULL 00/34] Migration staging patches peterx
2024-02-08 3:04 ` [PULL 01/34] migration: prevent migration when VM has poisoned memory peterx
2024-02-08 3:04 ` [PULL 02/34] migration/multifd: Drop stale comment for multifd zero copy peterx
2024-02-08 3:04 ` [PULL 03/34] migration/multifd: multifd_send_kick_main() peterx
2024-02-08 3:04 ` [PULL 04/34] migration/multifd: Drop MultiFDSendParams.quit, cleanup error paths peterx
2024-02-08 3:04 ` [PULL 05/34] migration/multifd: Postpone reset of MultiFDPages_t peterx
2024-02-08 3:05 ` [PULL 06/34] migration/multifd: Drop MultiFDSendParams.normal[] array peterx
2024-02-08 3:05 ` [PULL 07/34] migration/multifd: Separate SYNC request with normal jobs peterx
2024-02-08 3:05 ` [PULL 08/34] migration/multifd: Simplify locking in sender thread peterx
2024-02-08 3:05 ` [PULL 09/34] migration/multifd: Drop pages->num check " peterx
2024-02-08 3:05 ` [PULL 10/34] migration/multifd: Rename p->num_packets and clean it up peterx
2024-02-08 3:05 ` [PULL 11/34] migration/multifd: Move total_normal_pages accounting peterx
2024-02-08 3:05 ` [PULL 12/34] migration/multifd: Move trace_multifd_send|recv() peterx
2024-02-08 3:05 ` [PULL 13/34] migration/multifd: multifd_send_prepare_header() peterx
2024-02-08 3:05 ` [PULL 14/34] migration/multifd: Move header prepare/fill into send_prepare() peterx
2024-02-08 3:05 ` [PULL 15/34] migration/multifd: Forbid spurious wakeups peterx
2024-02-08 3:05 ` [PULL 16/34] migration/multifd: Split multifd_send_terminate_threads() peterx
2024-02-08 3:05 ` [PULL 17/34] migration/multifd: Change retval of multifd_queue_page() peterx
2024-02-08 3:05 ` [PULL 18/34] migration/multifd: Change retval of multifd_send_pages() peterx
2024-02-08 3:05 ` [PULL 19/34] migration/multifd: Rewrite multifd_queue_page() peterx
2024-02-08 3:05 ` [PULL 20/34] migration/multifd: Cleanup multifd_save_cleanup() peterx
2024-02-08 3:05 ` [PULL 21/34] migration/multifd: Cleanup multifd_load_cleanup() peterx
2024-02-08 3:05 ` [PULL 22/34] migration/multifd: Stick with send/recv on function names peterx
2024-02-08 3:05 ` [PULL 23/34] migration/multifd: Fix MultiFDSendParams.packet_num race peterx
2024-02-08 3:05 ` [PULL 24/34] migration/multifd: Optimize sender side to be lockless peterx
2024-02-08 3:05 ` [PULL 25/34] migration: Fix logic of channels and transport compatibility check peterx
2024-02-08 3:05 ` [PULL 26/34] migration/multifd: Join the TLS thread peterx
2024-02-10 9:18 ` Michael Tokarev
2024-02-10 9:30 ` Michael Tokarev
2024-02-14 13:27 ` Fabiano Rosas
2024-02-14 13:58 ` Michael Tokarev
2024-02-15 13:24 ` Fabiano Rosas [this message]
2024-02-08 3:05 ` [PULL 27/34] migration/multifd: Remove p->running peterx
2024-02-08 3:05 ` [PULL 28/34] migration/multifd: Move multifd_send_setup error handling in to the function peterx
2024-02-08 3:05 ` [PULL 29/34] migration/multifd: Move multifd_send_setup into migration thread peterx
2024-02-08 3:05 ` [PULL 30/34] migration/multifd: Unify multifd and TLS connection paths peterx
2024-02-08 3:05 ` [PULL 31/34] migration/multifd: Add a synchronization point for channel creation peterx
2024-02-08 3:05 ` [PULL 32/34] tests/migration-test: Stick with gicv3 in aarch64 test peterx
2024-02-08 3:05 ` [PULL 33/34] ci: Remove tag dependency for build-previous-qemu peterx
2024-02-08 3:05 ` [PULL 34/34] ci: Update comment for migration-compat-aarch64 peterx
2024-02-09 16:14 ` [PULL 00/34] Migration staging patches Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878r3lsvve.fsf@suse.de \
--to=farosas@suse.de \
--cc=mjt@tls.msk.ru \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).