From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Nico Boehr" <nrb@linux.ibm.com>, <frankja@linux.ibm.com>,
<imbrenda@linux.ibm.com>, <thuth@redhat.com>
Cc: <kvm@vger.kernel.org>, <linux-s390@vger.kernel.org>
Subject: Re: [kvm-unit-tests PATCH v1] arch-run: Wait for incoming socket being removed
Date: Tue, 12 Mar 2024 16:37:39 +1000 [thread overview]
Message-ID: <CZRKBTZFFB9Y.38GVXEXZPOVK5@wheely> (raw)
In-Reply-To: <20240305141214.707046-1-nrb@linux.ibm.com>
On Wed Mar 6, 2024 at 12:11 AM AEST, Nico Boehr wrote:
> Sometimes, QEMU needs a bit longer to remove the incoming migration
> socket. This happens in some environments on s390x for the
> migration-skey-sequential test.
>
> Instead of directly erroring out, wait for the removal of the socket.
>
> Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
It's interesting that the incoming socket is not removed after
QMP says migration complete. I guess that's by design, but have
you checked the QEMU code whether it's intentional?
I guess it's code like this - in migration/migration.c
/*
* This must happen after any state changes since as soon as an external
* observer sees this event they might start to prod at the VM assuming
* it's ready to use.
*/
migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE,
MIGRATION_STATUS_COMPLETED);
migration_incoming_state_destroy();
So, it looks like a good fix. And probably not just s390x specific
it might be just unlucky timing.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> scripts/arch-run.bash | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/arch-run.bash b/scripts/arch-run.bash
> index 2214d940cf7d..413f3eda8cb8 100644
> --- a/scripts/arch-run.bash
> +++ b/scripts/arch-run.bash
> @@ -237,12 +237,8 @@ do_migration ()
> echo > ${dst_infifo}
> rm ${dst_infifo}
>
> - # Ensure the incoming socket is removed, ready for next destination
> - if [ -S ${dst_incoming} ] ; then
> - echo "ERROR: Incoming migration socket not removed after migration." >& 2
> - qmp ${dst_qmp} '"quit"'> ${dst_qmpout} 2>/dev/null
> - return 2
> - fi
> + # Wait for the incoming socket being removed, ready for next destination
> + while [ -S ${dst_incoming} ] ; do sleep 0.1 ; done
>
> wait ${live_pid}
> ret=$?
next prev parent reply other threads:[~2024-03-12 6:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 14:11 [kvm-unit-tests PATCH v1] arch-run: Wait for incoming socket being removed Nico Boehr
2024-03-05 18:12 ` Marc Hartmayer
2024-03-06 13:03 ` Nico Boehr
2024-03-12 5:39 ` Nicholas Piggin
2024-03-12 6:37 ` Nicholas Piggin [this message]
2024-03-12 6:45 ` Thomas Huth
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=CZRKBTZFFB9Y.38GVXEXZPOVK5@wheely \
--to=npiggin@gmail.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.