All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH 06/21] migration: Remove checks for s->parameters has_* fields
Date: Fri, 6 Jun 2025 11:13:46 -0400	[thread overview]
Message-ID: <aEMFqt2j51V2U90E@x1.local> (raw)
In-Reply-To: <20250603013810.4772-7-farosas@suse.de>

On Mon, Jun 02, 2025 at 10:37:55PM -0300, Fabiano Rosas wrote:
> The migration parameters validation produces a temporary structure
> which is the merge of the current parameter values (s->parameters,
> MigrationParameters) with the new parameters set by the user
> (MigrateSetParameters).
> 
> When copying the values from s->parameters into the temporary
> structure, the has_* fields are copied along, but when merging the
> user-input values (MigrateSetParameters) they are not.
> 
> During migrate_params_check(), only the parameters that have the
> corresponding has_* field will be checked, so only the parameters that
> were initialized in migrate_params_init() will be validated.
> 
> This causes (almost) all of the migration parameters to be validated
> every time a parameter is set, regardless of which fields the user
> touched, but it also skips validation of any values that are not set
> in migrate_params_init().
> 
> It's not clear what was the intention of the original code, whether to
> validate all fields always, or only validate what the user input
> changed. Since the current situation is closer to the former option,
> make the choice of validating all parameters by removing the checks
> for the has_* fields when validating.
> 
> Note that bringing the user input into the temporary structure for
> validation still needs to look at the has_* fields, otherwise any
> parameters not set by the user (i.e. 0) would override the
> corresponding value in s->parameters.
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>

Reviewed-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu



  reply	other threads:[~2025-06-06 15:14 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03  1:37 [PATCH 00/21] migration: Unify capabilities and parameters Fabiano Rosas
2025-06-03  1:37 ` [PATCH 01/21] migration: Normalize tls arguments Fabiano Rosas
2025-06-05 20:51   ` Peter Xu
2025-06-06 13:48     ` Fabiano Rosas
2025-06-25  9:41   ` Markus Armbruster
2025-06-25 17:17     ` Fabiano Rosas
2025-06-26  9:38       ` Markus Armbruster
2025-06-26 14:51         ` Fabiano Rosas
2025-06-27  7:10           ` Markus Armbruster
2025-06-27 20:28             ` Fabiano Rosas
2025-07-01  7:08               ` Markus Armbruster
2025-07-01  9:05                 ` Daniel P. Berrangé
2025-06-03  1:37 ` [PATCH 02/21] migration: Remove MigrateSetParameters Fabiano Rosas
2025-06-05 20:58   ` Peter Xu
2025-06-25 11:31   ` Markus Armbruster
2025-06-25 17:21     ` Fabiano Rosas
2025-06-26  9:40       ` Markus Armbruster
2025-06-03  1:37 ` [PATCH 03/21] qapi/migration: Don't document MigrationParameter Fabiano Rosas
2025-06-05 21:00   ` Peter Xu
2025-06-25 12:04   ` Markus Armbruster
2025-06-25 12:22     ` Markus Armbruster
2025-06-25 17:29       ` Fabiano Rosas
2025-06-03  1:37 ` [PATCH 04/21] migration: Run a post update routine after setting parameters Fabiano Rosas
2025-06-03  1:37 ` [PATCH 05/21] migration: Add a flag to track block-bitmap-mapping input Fabiano Rosas
2025-06-06 15:03   ` Peter Xu
2025-06-06 15:43     ` Fabiano Rosas
2025-06-06 17:44       ` Peter Xu
2025-06-06 18:38         ` Fabiano Rosas
2025-06-03  1:37 ` [PATCH 06/21] migration: Remove checks for s->parameters has_* fields Fabiano Rosas
2025-06-06 15:13   ` Peter Xu [this message]
2025-06-03  1:37 ` [PATCH 07/21] migration: Set block_bitmap_mapping unconditionally in query-migrate-parameters Fabiano Rosas
2025-06-03  1:37 ` [PATCH 08/21] migration: Do away with usage of QERR_INVALID_PARAMETER_VALUE Fabiano Rosas
2025-06-06 15:17   ` Peter Xu
2025-06-03  1:37 ` [PATCH 09/21] migration: Extract code to mark all parameters as present Fabiano Rosas
2025-06-06 15:26   ` Peter Xu
2025-06-06 15:51     ` Fabiano Rosas
2025-06-06 17:48       ` Peter Xu
2025-06-03  1:37 ` [PATCH 10/21] migration: Use QAPI_CLONE_MEMBERS in query_migrate_parameters Fabiano Rosas
2025-06-06 15:29   ` Peter Xu
2025-06-06 15:53     ` Fabiano Rosas
2025-06-12 20:58       ` Fabiano Rosas
2025-06-12 21:27         ` Peter Xu
2025-06-13 12:30           ` Fabiano Rosas
2025-06-03  1:38 ` [PATCH 11/21] migration: Use QAPI_CLONE_MEMBERS in migrate_params_test_apply Fabiano Rosas
2025-06-03  1:38 ` [PATCH 12/21] migration: Use QAPI_CLONE_MEMBERS in migrate_params_apply Fabiano Rosas
2025-06-03  1:38 ` [PATCH 13/21] migration: Use visitors in migrate_params_test_apply Fabiano Rosas
2025-06-03  1:38 ` [PATCH 14/21] migration: Cleanup hmp_info_migrate_parameters Fabiano Rosas
2025-06-06 18:52   ` Peter Xu
2025-06-03  1:38 ` [PATCH 15/21] migration: Add capabilities into MigrationParameters Fabiano Rosas
2025-06-06 19:01   ` Peter Xu
2025-06-03  1:38 ` [PATCH 16/21] qapi/migration: Mark that query/set-migrate-parameters support capabilities Fabiano Rosas
2025-06-03  9:01   ` Daniel P. Berrangé
2025-06-06 13:53     ` Fabiano Rosas
2025-06-03  1:38 ` [PATCH 17/21] migration: Remove s->capabilities Fabiano Rosas
2025-06-06 19:16   ` Peter Xu
2025-06-03  1:38 ` [PATCH 18/21] qapi/migration: Deprecate capabilities commands Fabiano Rosas
2025-06-06 19:16   ` Peter Xu
2025-06-03  1:38 ` [PATCH 19/21] migration: Allow migrate commands to provide the migration config Fabiano Rosas
2025-06-03  9:03   ` Daniel P. Berrangé
2025-06-06 19:28   ` Peter Xu
2025-06-06 20:23     ` Fabiano Rosas
2025-06-06 20:50       ` Peter Xu
2025-06-09 14:37         ` Fabiano Rosas
2025-06-09 15:51           ` Peter Xu
2025-06-09 16:13             ` Daniel P. Berrangé
2025-06-09 16:49               ` Peter Xu
2025-06-09 18:17                 ` Fabiano Rosas
2025-06-09 18:02             ` Fabiano Rosas
2025-06-09 19:05               ` Peter Xu
2025-06-09 19:41                 ` Fabiano Rosas
2025-06-09 20:35                   ` Peter Xu
2025-06-10 20:55                     ` Fabiano Rosas
2025-06-10 21:27                       ` Peter Xu
2025-06-09 15:03         ` Daniel P. Berrangé
2025-06-09 15:33           ` Peter Xu
2025-06-09 15:43             ` Daniel P. Berrangé
2025-06-09 15:53               ` Peter Xu
2025-06-09 15:58                 ` Peter Xu
2025-06-09 16:15                 ` Daniel P. Berrangé
2025-06-09 16:41                   ` Peter Xu
2025-06-03  1:38 ` [PATCH 20/21] libqtest: Add a function to check whether a QMP command supports a feature Fabiano Rosas
2025-06-03  1:38 ` [PATCH 21/21] tests/qtest/migration: Add a test for config passing Fabiano Rosas
2025-06-12  6:41 ` [PATCH 00/21] migration: Unify capabilities and parameters Mario Casquero

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=aEMFqt2j51V2U90E@x1.local \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --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.