From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dave@treblig.org>
Cc: Juraj Marcin <jmarcin@redhat.com>,
Jiri Denemark <jdenemar@redhat.com>,
qemu-devel@nongnu.org, Stefan Weil <sw@weilnetz.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Fabiano Rosas <farosas@suse.de>
Subject: Re: [RFC PATCH 0/4] migration: Introduce postcopy-setup capability and state
Date: Wed, 3 Sep 2025 09:07:45 -0400 [thread overview]
Message-ID: <aLg9oYlaougF1-dv@x1.local> (raw)
In-Reply-To: <aLgtyy_UAfsmOLET@gallifrey>
On Wed, Sep 03, 2025 at 12:00:11PM +0000, Dr. David Alan Gilbert wrote:
> So I wonder what libvirt uses to trigger it starting the destination in
> the postcopy case? It's got to be after the device state has loaded.
qmp_cont() supports the "autostart" variable:
if (runstate_check(RUN_STATE_INMIGRATE)) {
autostart = 1;
} else {
That's since commit 1e9981465f ("qmp: handle stop/cont in INMIGRATE
state"). The commit message also mentioned libvirt used to use a loop
somehow.. and I'm surprised to know it wasn't trying to fix the libvirt
problem but something else..
That makes sense, as any delay on cont would be accounted as downtime (even
if trivially), if only executed after loading complete event.
--
Peter Xu
next prev parent reply other threads:[~2025-09-03 13:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 11:49 [RFC PATCH 0/4] migration: Introduce postcopy-setup capability and state Juraj Marcin
2025-08-07 11:49 ` [RFC PATCH 1/4] qemu-thread: Introduce qemu_thread_detach() Juraj Marcin
2025-08-19 10:37 ` Daniel P. Berrangé
2025-08-07 11:49 ` [RFC PATCH 2/4] migration: Fix state transition in postcopy_start() error handling Juraj Marcin
2025-08-07 20:54 ` Peter Xu
2025-08-08 9:44 ` Juraj Marcin
2025-08-08 16:00 ` Peter Xu
2025-08-08 19:08 ` Fabiano Rosas
2025-08-11 13:00 ` Juraj Marcin
2025-08-07 11:49 ` [RFC PATCH 3/4] migration: Make listen thread joinable Juraj Marcin
2025-08-07 20:57 ` Peter Xu
2025-08-08 11:08 ` Juraj Marcin
2025-08-08 17:05 ` Peter Xu
2025-08-11 13:02 ` Juraj Marcin
2025-08-07 11:49 ` [RFC PATCH 4/4] migration: Introduce postcopy-setup capability and state Juraj Marcin
2025-08-11 14:54 ` [RFC PATCH 0/4] " Peter Xu
2025-08-12 13:34 ` Juraj Marcin
2025-08-13 17:42 ` Peter Xu
2025-08-14 15:42 ` Juraj Marcin
2025-08-14 19:24 ` Peter Xu
2025-08-15 6:35 ` Juraj Marcin
2025-09-01 17:57 ` Dr. David Alan Gilbert
2025-09-02 8:30 ` Juraj Marcin
2025-09-03 12:00 ` Dr. David Alan Gilbert
2025-09-03 13:07 ` Peter Xu [this message]
2025-09-04 16:11 ` Juraj Marcin
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=aLg9oYlaougF1-dv@x1.local \
--to=peterx@redhat.com \
--cc=dave@treblig.org \
--cc=farosas@suse.de \
--cc=jdenemar@redhat.com \
--cc=jmarcin@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
/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.