qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, "Fabiano Rosas" <farosas@suse.de>,
	"Dr . David Alan Gilbert" <dave@treblig.org>,
	"Eric Blake" <eblake@redhat.com>, "Kevin Wolf" <kwolf@redhat.com>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@yandex-team.ru>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Andrey Drobyshev" <andrey.drobyshev@virtuozzo.com>,
	peterx@redhat.com, "Stefan Hajnoczi" <stefanha@redhat.com>
Subject: [PATCH RFC 02/11] migration/block: Make late-block-active the default
Date: Tue,  3 Dec 2024 19:51:29 -0500	[thread overview]
Message-ID: <20241204005138.702289-3-peterx@redhat.com> (raw)
In-Reply-To: <20241204005138.702289-1-peterx@redhat.com>

Migration capability 'late-block-active' controls when the block drives
will be activated.  If enabled, block drives will only be activated until
VM starts, either src runstate was "live" (RUNNING, or SUSPENDED), or it'll
be postponed until qmp_cont().

Let's do this unconditionally.  There's no harm to delay activation of
block drives.  Meanwhile there's no ABI breakage if dest does it, because
src QEMU has nothing to do with it, so it's no concern on ABI breakage.

IIUC we could avoid introducing this cap when introducing it before, but
now it's still not too late to just always do it.  Cap now prone to
removal, but it'll be for later patches.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 migration/migration.c | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index d2a6b939cf..e6db9cfc50 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -743,24 +743,6 @@ static void process_incoming_migration_bh(void *opaque)
 
     trace_vmstate_downtime_checkpoint("dst-precopy-bh-enter");
 
-    /* If capability late_block_activate is set:
-     * Only fire up the block code now if we're going to restart the
-     * VM, else 'cont' will do it.
-     * This causes file locking to happen; so we don't want it to happen
-     * unless we really are starting the VM.
-     */
-    if (!migrate_late_block_activate() ||
-        (autostart && runstate_is_live(migration_get_target_runstate()))) {
-        /* Make sure all file formats throw away their mutable metadata.
-         * If we get an error here, just don't restart the VM yet. */
-        bdrv_activate_all(&local_err);
-        if (local_err) {
-            error_report_err(local_err);
-            local_err = NULL;
-            autostart = false;
-        }
-    }
-
     /*
      * This must happen after all error conditions are dealt with and
      * we're sure the VM is going to be running on this host.
@@ -775,7 +757,25 @@ static void process_incoming_migration_bh(void *opaque)
 
     if (runstate_is_live(migration_get_target_runstate())) {
         if (autostart) {
-            vm_start();
+            /*
+             * Block activation is always delayed until VM starts, either
+             * here (which means we need to start the dest VM right now..),
+             * or until qmp_cont() later.
+             *
+             * We used to have cap 'late-block-activate' but now we do this
+             * unconditionally, as it has no harm but only benefit.  E.g.,
+             * it's not part of migration ABI on the time of disk activation.
+             *
+             * Make sure all file formats throw away their mutable
+             * metadata.  If error, don't restart the VM yet.
+             */
+            bdrv_activate_all(&local_err);
+            if (local_err) {
+                error_report_err(local_err);
+                local_err = NULL;
+            } else {
+                vm_start();
+            }
         } else {
             runstate_set(RUN_STATE_PAUSED);
         }
-- 
2.47.0



  parent reply	other threads:[~2024-12-04  0:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04  0:51 [PATCH RFC 00/11] migration/block: disk activation rewrite Peter Xu
2024-12-04  0:51 ` [PATCH RFC 01/11] migration: Add helper to get target runstate Peter Xu
2024-12-04  0:51 ` Peter Xu [this message]
2024-12-04  0:51 ` [PATCH RFC 03/11] migration/block: Apply late-block-active behavior to postcopy Peter Xu
2024-12-04  0:51 ` [PATCH RFC 04/11] migration/block: Fix possible race with block_inactive Peter Xu
2024-12-04  0:51 ` [PATCH RFC 05/11] migration/block: Merge block reactivations for fail/cancel Peter Xu
2024-12-04  0:51 ` [PATCH RFC 06/11] migration/block: Extend the migration_block_* API to dest side Peter Xu
2024-12-04 14:49   ` Peter Xu
2024-12-04  0:51 ` [PATCH RFC 07/11] migration/block: Apply the migration_block_* API to postcopy Peter Xu
2024-12-04  0:51 ` [PATCH RFC 08/11] tests/qtest/migration: Move more code under only_target Peter Xu
2024-12-04  0:51 ` [PATCH RFC 09/11] tests/qtest/migration: Don't use hardcoded strings for -serial Peter Xu
2024-12-04 19:11   ` Fabiano Rosas
2024-12-04  0:51 ` [PATCH RFC 10/11] tests/qtest/migration: Support cleaning up only one side of migration Peter Xu
2024-12-04  0:51 ` [PATCH RFC 11/11] tests/qtest/migration: Test successive migrations Peter Xu
2024-12-04 17:25 ` [PATCH RFC 00/11] migration/block: disk activation rewrite Peter Xu

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=20241204005138.702289-3-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=andrey.drobyshev@virtuozzo.com \
    --cc=berrange@redhat.com \
    --cc=dave@treblig.org \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@yandex-team.ru \
    /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).