From: Juan Quintela <quintela@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
michael.roth@amd.com, armbru@redhat.com, eblake@redhat.com,
jasowang@redhat.com, zhanghailiang@xfusion.com,
philmd@linaro.org, thuth@redhat.com, berrange@redhat.com,
marcandre.lureau@redhat.com, pbonzini@redhat.com,
dave@treblig.org, hreitz@redhat.com, kwolf@redhat.com,
chen.zhang@intel.com, lizhijian@fujitsu.com
Subject: Re: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION
Date: Thu, 20 Apr 2023 12:03:28 +0200 [thread overview]
Message-ID: <87h6tazx8v.fsf@secure.mitica> (raw)
In-Reply-To: <20230419225232.508121-4-vsementsov@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Thu, 20 Apr 2023 01:52:31 +0300")
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> wrote:
> We don't allow to use x-colo capability when replication is not
> configured. So, no reason to build COLO when replication is disabled,
> it's unusable in this case.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> +bool migrate_colo_enabled(void)
> +{
> + MigrationState *s = migrate_get_current();
> + return s->enabled_capabilities[MIGRATION_CAPABILITY_X_COLO];
> +}
I consolidated all the capabilities check on my series on the list on
options.c, so this will go there.
> diff --git a/migration/migration.c b/migration/migration.c
> index bda4789193..2382958364 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -165,7 +165,9 @@ INITIALIZE_MIGRATE_CAPS_SET(check_caps_background_snapshot,
> MIGRATION_CAPABILITY_RDMA_PIN_ALL,
> MIGRATION_CAPABILITY_COMPRESS,
> MIGRATION_CAPABILITY_XBZRLE,
> +#ifdef CONFIG_REPLICATION
> MIGRATION_CAPABILITY_X_COLO,
> +#endif
Why?
I very much preffer the capability to be there and just fail when we try
to enable it. That way we only need the #ifdef in one place and not all
over the place.
> MIGRATION_CAPABILITY_VALIDATE_UUID,
> MIGRATION_CAPABILITY_ZERO_COPY_SEND);
>
> @@ -1329,15 +1331,6 @@ static bool migrate_caps_check(bool *cap_list,
> }
> #endif
>
> -#ifndef CONFIG_REPLICATION
> - if (cap_list[MIGRATION_CAPABILITY_X_COLO]) {
> - error_setg(errp, "QEMU compiled without replication module"
> - " can't enable COLO");
> - error_append_hint(errp, "Please enable replication before COLO.\n");
> - return false;
> - }
> -#endif
> -
See, like this O:-)
> diff --git a/qapi/migration.json b/qapi/migration.json
> index c84fa10e86..93863fa88c 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -486,7 +486,8 @@
> { 'enum': 'MigrationCapability',
> 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> 'compress', 'events', 'postcopy-ram',
> - { 'name': 'x-colo', 'features': [ 'unstable' ] },
> + { 'name': 'x-colo', 'features': [ 'unstable' ],
> + 'if': 'CONFIG_REPLICATION' },
> 'release-ram',
> 'block', 'return-path', 'pause-before-switchover', 'multifd',
> 'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
Aha, It is for this that you changed the black magic on the previous
patch. Looks ok from my ignorance. As said before, I would not remove
the capability, left it the way it was.
You have less code (less #ifdefs that you just had to add), and
enabling/disabling checking capabilities don't need anything from replication.
> #
> ##
> { 'command': 'x-colo-lost-heartbeat',
> - 'features': [ 'unstable' ] }
> + 'features': [ 'unstable' ],
> + 'if': 'CONFIG_REPLICATION' }
>
> ##
> # @migrate_cancel:
> @@ -1685,7 +1687,8 @@
> ##
> { 'struct': 'COLOStatus',
> 'data': { 'mode': 'COLOMode', 'last-mode': 'COLOMode',
> - 'reason': 'COLOExitReason' } }
> + 'reason': 'COLOExitReason' },
> + 'if': 'CONFIG_REPLICATION' }
>
> ##
> # @query-colo-status:
> @@ -1702,7 +1705,8 @@
> # Since: 3.1
> ##
> { 'command': 'query-colo-status',
> - 'returns': 'COLOStatus' }
> + 'returns': 'COLOStatus',
> + 'if': 'CONFIG_REPLICATION' }
>
> ##
> # @migrate-recover:
Disabling the command is ok for me.
> diff --git a/stubs/colo.c b/stubs/colo.c
> new file mode 100644
> index 0000000000..45c8ac0cc6
...
> +bool migrate_colo_enabled(void)
> +{
> + return false;
> +}
You don't need this one if you follow my idea.
Notice that I fully agree with being able to disable colo O:-)
Later, Juan.
next prev parent reply other threads:[~2023-04-20 10:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 22:52 [PATCH v2 0/4] COLO: improve build options Vladimir Sementsov-Ogievskiy
2023-04-19 22:52 ` [PATCH v2 1/4] block/meson.build: prefer positive condition for replication Vladimir Sementsov-Ogievskiy
2023-04-20 9:51 ` Juan Quintela
2023-04-20 13:47 ` Philippe Mathieu-Daudé
2023-04-19 22:52 ` [PATCH v2 2/4] scripts/qapi: allow optional experimental enum values Vladimir Sementsov-Ogievskiy
2023-04-20 9:55 ` Juan Quintela
2023-04-20 14:43 ` Eric Blake
2023-04-20 16:47 ` Vladimir Sementsov-Ogievskiy
2023-04-19 22:52 ` [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION Vladimir Sementsov-Ogievskiy
2023-04-20 10:03 ` Juan Quintela [this message]
2023-04-20 11:40 ` Vladimir Sementsov-Ogievskiy
2023-04-20 11:56 ` Juan Quintela
2023-04-20 21:08 ` Dr. David Alan Gilbert
2023-04-21 3:02 ` Zhang, Chen
2023-04-21 8:35 ` Vladimir Sementsov-Ogievskiy
2023-04-23 1:54 ` Zhang, Chen
2023-04-27 19:31 ` Vladimir Sementsov-Ogievskiy
2023-04-28 6:52 ` Juan Quintela
2023-04-19 22:52 ` [PATCH v2 4/4] configure: add --disable-colo-filters option Vladimir Sementsov-Ogievskiy
2023-04-20 9:09 ` Zhang, Chen
2023-04-20 10:09 ` Lukas Straub
2023-04-20 11:25 ` Vladimir Sementsov-Ogievskiy
2023-04-21 2:22 ` Zhang, Chen
2023-04-21 8:52 ` Vladimir Sementsov-Ogievskiy
2023-04-23 2:05 ` Zhang, Chen
2023-04-20 8:33 ` [PATCH v2 0/4] COLO: improve build options Lukas Straub
2023-04-20 8:39 ` Vladimir Sementsov-Ogievskiy
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=87h6tazx8v.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=chen.zhang@intel.com \
--cc=dave@treblig.org \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=lizhijian@fujitsu.com \
--cc=marcandre.lureau@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vsementsov@yandex-team.ru \
--cc=zhanghailiang@xfusion.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 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).