From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [RFC PATCH 04/13] migration: Fix parameter validation
Date: Mon, 26 May 2025 12:41:21 -0300 [thread overview]
Message-ID: <87bjrfv0pq.fsf@suse.de> (raw)
In-Reply-To: <aDRoFH-oXq_AiJCP@x1.local>
Peter Xu <peterx@redhat.com> writes:
> On Thu, May 22, 2025 at 02:39:48PM -0300, Fabiano Rosas wrote:
>> Actually, this doesn't work...
>>
>> The migrate-set-* commands have optional fields, so we need some form of
>> checking has_* to know which fields the user is setting. Otherwise
>> MigrationSetParameters will have zeros all over that will trip the
>> check.
>>
>> Then, we need some form of checking has_* to be able to enventually get
>> the values into s->config (former s->parameters/capabilities), otherwise
>> we'll overwrite the already-set values with the potentially empty ones
>> coming from QAPI.
>>
>> Then there's also the issue of knowing whether a value is 0 because the
>> user set it 0 or because it was never set.
>>
>> We also can't apply an invalid value to s->config and validate it after
>> because some parameters are allowed to be changed during migration.
>
> What I meant was we only conditionally ignore the has_* fields in below:
>
> (1) migrate_params_check(), so that QEMU always checks all parameters in
> the MigrationParameters* specified when invoking the function.
>
Yes, I realised later that's what you meant. I'm looking into
it. Hitting some issues with the block_bitmap_mapping option, which
seems to be able to become NULL even if has_block_bitmap_mapping is
true. According to commit 3cba22c9ad ("migration: Fix
block_bitmap_mapping migration").
> (2) MigrationState.parameters, so that as long as the parameters are
> applied (it should only happen after sanity check all pass..) then we
> ignore these has_* fields (until MigrationState.parameters can have a
> better struct to not include these has_* fields).
>
> We can keep the has_* checks in migrate_params_test_apply() and
> migrate_params_apply(), so that we won't touch the ones the user didn't
> specify in the QMP commands as you said.
>
> The benefits of having above 1/2 ignoring has_* is some code removal where
> we assume has_* always are TRUEs.
>
> This can be still a bit confusing, but at least we don't need to init has_*
> fields in migrate_params_init() anymore as they'll be all ignored, then
> there's no chance we forget set TRUEs to any new params either.
next prev parent reply other threads:[~2025-05-26 15:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 19:14 [RFC PATCH 00/13] migration: Unify capabilities and parameters Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 01/13] migration: Fix latent bug in migrate_params_test_apply() Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 02/13] migration: Normalize tls arguments Fabiano Rosas
2025-04-14 16:30 ` Daniel P. Berrangé
2025-04-11 19:14 ` [RFC PATCH 03/13] migration: Run a post update routine after setting parameters Fabiano Rosas
2025-05-15 20:42 ` Peter Xu
2025-04-11 19:14 ` [RFC PATCH 04/13] migration: Fix parameter validation Fabiano Rosas
2025-05-15 20:59 ` Peter Xu
2025-05-22 16:39 ` Fabiano Rosas
2025-05-22 17:39 ` Fabiano Rosas
2025-05-26 13:09 ` Peter Xu
2025-05-26 15:41 ` Fabiano Rosas [this message]
2025-04-11 19:14 ` [RFC PATCH 05/13] migration: Reduce a bit of duplication in migration.json Fabiano Rosas
2025-04-14 16:38 ` Daniel P. Berrangé
2025-04-14 17:02 ` Fabiano Rosas
2025-04-16 13:38 ` Markus Armbruster
2025-04-16 14:41 ` Fabiano Rosas
2025-04-17 5:56 ` Markus Armbruster
2025-04-17 18:45 ` Markus Armbruster
2025-04-18 6:40 ` Markus Armbruster
2025-04-11 19:14 ` [RFC PATCH 06/13] migration: Remove the parameters copy during validation Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 07/13] migration: Introduce new MigrationConfig structure Fabiano Rosas
2025-04-18 7:03 ` Markus Armbruster
2025-05-23 13:38 ` Fabiano Rosas
2025-05-26 7:37 ` Markus Armbruster
2025-04-11 19:14 ` [RFC PATCH 08/13] migration: Replace s->parameters with s->config Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 09/13] migration: Do away with usage of QERR_INVALID_PARAMETER_VALUE Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 10/13] migration: Replace s->capabilities with s->config Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 11/13] migration: Merge parameters and capability checks Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 12/13] [PoC] migration: Add query/set commands for MigrationConfig Fabiano Rosas
2025-05-26 7:51 ` Markus Armbruster
2025-05-27 22:14 ` Fabiano Rosas
2025-04-11 19:14 ` [RFC PATCH 13/13] [PoC] migration: Allow migrate commands to provide the migration config Fabiano Rosas
2025-05-26 8:03 ` Markus Armbruster
2025-05-26 15:10 ` Peter Xu
2025-04-14 16:44 ` [RFC PATCH 00/13] migration: Unify capabilities and parameters Daniel P. Berrangé
2025-04-14 17:12 ` Fabiano Rosas
2025-04-14 17:20 ` Daniel P. Berrangé
2025-04-14 17:40 ` Fabiano Rosas
2025-04-14 19:06 ` Daniel P. Berrangé
2025-05-15 20:21 ` Peter Xu
2025-04-16 13:44 ` Markus Armbruster
2025-04-16 15:00 ` Fabiano Rosas
2025-04-24 9:35 ` Markus Armbruster
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=87bjrfv0pq.fsf@suse.de \
--to=farosas@suse.de \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=peterx@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 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.