From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, "Juraj Marcin" <jmarcin@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH 0/3] migration/tls: Graceful shutdowns for main and postcopy channels
Date: Thu, 18 Sep 2025 12:15:53 -0400 [thread overview]
Message-ID: <aMwwOfX8lL25aLf7@x1.local> (raw)
In-Reply-To: <87ikhfvpmj.fsf@suse.de>
On Thu, Sep 18, 2025 at 10:47:48AM -0300, Fabiano Rosas wrote:
> I'm thinking if it's possible for a premature termination to be detected
> by TLS before we did the shutdown(). So my suggestion was to always
> bye() before shutdown(), not matter the state migration is in. But maybe
> your way is ok, I'm not sure now. Let me read the other versions of the
> series...
For failing / cancelling migrations, premature termination is likely fine.
IMHO we also shouldn't care too much on error reports on premature
terminations because it's failing anyway.
So maybe you're talking about shutdown()s when the migration is
successfully completed.
We can try to do that, but maybe it's not easily doable. E.g., we have the
preempt thread currently only be able to be kicked out by a shutdown() from
the dst main thread. While we can start to inject a bye() there before the
shutdown(), it'll be:
(1) a bye() sent concurrently while the preempt thread is still logically
owning and operating on the preempt channel (luckily, so far read-only),
and,
(2) we need to double check if this works if we send bye(WR) from dest to
src and whether it'll also gracefully shutdown the src side.
(3) currently, a shutdown() is synchronous. bye() is yet not. We may
then need similiar treatment (e.g. changing IO to block tempoararily?)
when doing explicit shutdown()s.
I very vaguely remember when working on this series I tried (2) and it
didn't really work, but I'm not very sure. Anyway, all these will add some
complexity, and we'd better justify it's worthwhile..
[...]
> Ah, sorry, I didn't see the v2 on my list. But it's there.
Nah, that's not your fault, maybe mine.
--
Peter Xu
prev parent reply other threads:[~2025-09-18 16:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 16:01 [PATCH 0/3] migration/tls: Graceful shutdowns for main and postcopy channels Peter Xu
2025-09-10 16:01 ` [PATCH 1/3] migration/tls: Gracefully shutdown main and preempt channels Peter Xu
2025-09-17 20:22 ` Fabiano Rosas
2025-09-10 16:01 ` [PATCH 2/3] migration: Make migration_has_failed() work even for CANCELLING Peter Xu
2025-09-17 20:52 ` Fabiano Rosas
2025-09-17 22:00 ` Peter Xu
2025-09-18 13:43 ` Fabiano Rosas
2025-09-10 16:01 ` [PATCH 3/3] migration/multifd: Use the new graceful termination helper Peter Xu
2025-09-17 21:07 ` Fabiano Rosas
2025-09-11 13:13 ` [PATCH 0/3] migration/tls: Graceful shutdowns for main and postcopy channels Peter Xu
2025-09-17 20:56 ` Fabiano Rosas
2025-09-17 21:50 ` Peter Xu
2025-09-18 13:47 ` Fabiano Rosas
2025-09-18 16:15 ` Peter Xu [this message]
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=aMwwOfX8lL25aLf7@x1.local \
--to=peterx@redhat.com \
--cc=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=qemu-devel@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).