From: Peter Xu <peterx@redhat.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
David Hildenbrand <david@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Eduardo Habkost <eduardo@habkost.net>,
Philippe Mathieu-Daude <philmd@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [RFC V1 05/14] migration: init and listen during precreate
Date: Mon, 21 Oct 2024 12:41:00 -0400 [thread overview]
Message-ID: <ZxaEHLa7LP5DCkYf@x1n> (raw)
In-Reply-To: <1729178055-207271-6-git-send-email-steven.sistare@oracle.com>
On Thu, Oct 17, 2024 at 08:14:06AM -0700, Steve Sistare wrote:
> Initialize the migration object as early as possible so that migration
> configuration commands may be sent during the precreate phase. Also,
> start listening for the incoming migration connection during precreate,
> so that the listen port number is assigned (if dynamic), and the user
> can discover it during precreate via query-migrate. The precreate phase
> will be delineated in a subsequent patch.
>
> The code previously called migration_object_init after memory backends
> were created so that a subsequent migrate-set-capabilities call to set
> MIGRATION_CAPABILITY_POSTCOPY_RAM would verify all backends support
> postcopy. See migrate_caps_check and postcopy_ram_supported_by_host.
> The new code calls migration_object_init before backends are created.
> However, migrate-set-capabilities will only be received during the
> precreate phase for CPR, and CPR does not support postcopy. If the
> precreate phase is generalized in the future, then the ram compatibility
> check must be deferred to the start of migration.
This makes sense to me on its own, so maybe we can have a seperate patch.
We should probably always do the check at start of migration, to avoid
postcopy-ram cap set followed by an memory plug which doesn't support
postcopy.
>
> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> ---
> system/vl.c | 35 +++++++++++++----------------------
> 1 file changed, 13 insertions(+), 22 deletions(-)
>
> diff --git a/system/vl.c b/system/vl.c
> index bca2292..d32203c 100644
> --- a/system/vl.c
> +++ b/system/vl.c
> @@ -2753,17 +2753,7 @@ void qmp_x_exit_preconfig(Error **errp)
> replay_vmstate_init();
> }
>
> - if (incoming) {
> - Error *local_err = NULL;
> - if (strcmp(incoming, "defer") != 0) {
> - qmp_migrate_incoming(incoming, false, NULL, true, true,
> - &local_err);
> - if (local_err) {
> - error_reportf_err(local_err, "-incoming %s: ", incoming);
> - exit(1);
> - }
> - }
> - } else if (autostart) {
> + if (!incoming && autostart) {
> qmp_cont(NULL);
> }
> }
> @@ -3751,6 +3741,18 @@ void qemu_init(int argc, char **argv)
> * called from do_configure_accelerator().
> */
>
> + /* Creates a QOM object */
Shall we still keep the ordering notes for global/compat properties to be
set before this one? "create QOM object" on its own isn't much of help as
a comment if the function has a proper name..
> + migration_object_init();
> +
> + if (incoming && !g_str_equal(incoming, "defer")) {
> + Error *local_err = NULL;
> + qmp_migrate_incoming(incoming, false, NULL, true, true, &local_err);
> + if (local_err) {
> + error_reportf_err(local_err, "-incoming %s: ", incoming);
> + exit(1);
> + }
> + }
> +
> suspend_mux_open();
>
> qemu_disable_default_devices();
> @@ -3773,20 +3775,9 @@ void qemu_init(int argc, char **argv)
> machine_class->name, machine_class->deprecation_reason);
> }
>
> - /*
> - * Create backends before creating migration objects, so that it can
> - * check against compatibilities on the backend memories (e.g. postcopy
> - * over memory-backend-file objects).
> - */
(so if there'll be a separate patch to delay postcopy ram check on src,
this removal can be part of it)
> qemu_create_late_backends();
> phase_advance(PHASE_LATE_BACKENDS_CREATED);
>
> - /*
> - * Note: creates a QOM object, must run only after global and
> - * compat properties have been set up.
> - */
> - migration_object_init();
> -
> /* parse features once if machine provides default cpu_type */
> current_machine->cpu_type = machine_class_default_cpu_type(machine_class);
> if (cpu_option) {
> --
> 1.8.3.1
>
--
Peter Xu
next prev parent reply other threads:[~2024-10-21 16:41 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:14 [RFC V1 00/14] precreate phase Steve Sistare
2024-10-17 15:14 ` [RFC V1 01/14] accel: encapsulate search state Steve Sistare
2024-10-21 20:03 ` Fabiano Rosas
2024-10-17 15:14 ` [RFC V1 02/14] accel: accel preinit function Steve Sistare
2024-10-17 15:26 ` Steven Sistare
2024-10-21 14:54 ` Peter Xu
2024-10-23 16:13 ` Steven Sistare
2024-10-23 15:53 ` Paolo Bonzini
2024-10-23 16:25 ` Steven Sistare
2024-10-17 15:14 ` [RFC V1 03/14] accel: split configure_accelerators Steve Sistare
2024-10-17 15:14 ` [RFC V1 04/14] accel: set accelerator and machine props earlier Steve Sistare
2024-10-18 15:08 ` Fabiano Rosas
2024-10-18 15:32 ` Steven Sistare
2024-10-18 15:40 ` Steven Sistare
2024-10-18 19:15 ` Steven Sistare
2024-10-21 16:20 ` Peter Xu
2024-10-23 17:16 ` Paolo Bonzini
2024-10-22 8:30 ` David Hildenbrand
2024-10-23 20:28 ` Steven Sistare
2024-10-21 15:19 ` Peter Xu
2024-10-23 20:29 ` Steven Sistare
2024-10-23 16:00 ` Paolo Bonzini
2024-10-23 17:18 ` Paolo Bonzini
2024-10-23 20:29 ` Steven Sistare
2024-10-17 15:14 ` [RFC V1 05/14] migration: init and listen during precreate Steve Sistare
2024-10-21 16:41 ` Peter Xu [this message]
2024-10-21 21:05 ` Fabiano Rosas
2024-10-23 16:01 ` Steven Sistare
2024-10-17 15:14 ` [RFC V1 06/14] vl: precreate phase Steve Sistare
2024-10-23 14:03 ` Fabiano Rosas
2024-10-17 15:14 ` [RFC V1 07/14] monitor: chardev name Steve Sistare
2024-10-17 15:14 ` [RFC V1 08/14] qom: get properties Steve Sistare
2024-10-17 15:14 ` [RFC V1 09/14] qemu-option: filtered foreach Steve Sistare
2024-10-17 15:14 ` [RFC V1 10/14] qemu-options: pass object to filter Steve Sistare
2024-10-17 15:14 ` [RFC V1 11/14] monitor: connect in precreate Steve Sistare
2024-10-21 19:28 ` Peter Xu
2024-10-23 17:34 ` Steven Sistare
2024-10-23 16:05 ` Paolo Bonzini
2024-10-23 17:35 ` Steven Sistare
2024-10-17 15:14 ` [RFC V1 12/14] qtest: " Steve Sistare
2024-10-17 15:14 ` [RFC V1 13/14] net: cleanup for precreate phase Steve Sistare
2024-10-17 15:27 ` Steven Sistare
2024-10-21 19:20 ` Peter Xu
2024-10-23 17:43 ` Steven Sistare
2024-10-17 15:14 ` [RFC V1 14/14] migration: allow commands during precreate and preconfig Steve Sistare
2024-10-21 19:36 ` Peter Xu
2024-10-23 17:50 ` Steven Sistare
2024-10-17 15:19 ` [RFC V1 00/14] precreate phase Steven Sistare
2024-10-17 15:53 ` Peter Xu
2024-10-21 15:56 ` Steven Sistare
2024-10-23 16:31 ` Paolo Bonzini
2024-10-24 21:16 ` Steven Sistare
2024-10-25 8:46 ` Daniel P. Berrangé
2024-10-25 13:33 ` Steven Sistare
2024-10-25 13:43 ` Daniel P. Berrangé
2024-10-25 14:32 ` Steven Sistare
2024-10-25 14:49 ` Daniel P. Berrangé
2024-10-28 21:56 ` Peter Xu
2024-10-29 9:09 ` Daniel P. Berrangé
2024-10-29 11:13 ` Daniel P. Berrangé
2024-10-29 13:20 ` Fabiano Rosas
2024-10-29 15:18 ` Peter Xu
2024-10-29 15:58 ` Daniel P. Berrangé
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=ZxaEHLa7LP5DCkYf@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=david@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.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.