[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 09/10] migration: merge enforce_config_sectio
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH v6 09/10] migration: merge enforce_config_section somewhat |
Date: |
Thu, 29 Jun 2017 11:00:13 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote:
> Eduardo Habkost <address@hidden> wrote:
>
> >
> > So, this is a case where a user-provided config option (-machine
> > enforce-config-section) should trigger a different default in another
> > class (migration.send-configuration).
> >
> > Also, the new default triggered by -machine has a very specific
> > priority:
> >
> > * AccelClass::global_props must not override "-machine
> > enforce-config-section=on"
> > * MachineClass::compat_props must not override
> > "-machine enforce-config-section=on"
> >
> > We must also decide in advance what should be result of:
> > * "-machine enforce-config-section=on -global
> > migration.send-configuration=off"
> > * "-machine enforce-config-section=off -global
> > migration.send-configuration=on"
> > * "-global migration.send-configuration=off -machine
> > enforce-config-section=off"
> > * "-global migration.send-configuration=on -machine
> > enforce-config-section=on"
Yes, this is considered before this patch: currently
enforce-config-section will have the highest priority in case if
someone used both of the old & new parameters for it (considering
"enforce-config-section" has the word "enforce" inside, it makes some
sense). While...
>
> BOOM!!!!!
>
> We use old configuration or new one.
... I agree more with Juan here, that user should not really specify
these two parameters at the same time. If the user knows the new
parameter, he/she should know that the new one is obsoleting the old
one. And since even for that case this patch can handle it well (will
take -M param), I think it's okay.
>
> >
> > I'm not sure what we should decide about these 4 cases above, but I
> > believe it would be safer to encode that decision at the same place we
> > handle the priority between accel/machine/user globals:
> > register_global_properties() at vl.c.
> >
> >
> > Or maybe this extra complexity is a sign that we shouldn't try to add
> > extra magic to make -machine affect the "migration" object properties,
> > and keep the existing machine->enforce_config_section check in the
> > migration code? I'm not sure.
>
> Not sure there either. I preffer doing it in a single place, but I am
> not the expert here.
IMHO it is not necessary to introduce such a thing in
register_global_properties(). AFAIU this is the only place where one
machine property can collapse with a global property? And it currently
only happens in migration codes. Actually it is well ordered, since we
init the migration object after register_global_properties(), so
everthing should possibly be fine. Introducing framework-level thing
for this may only make things more complicated imho.
After all we can remove all these one day when we can obsolete the
"enforce-config-section" parameter (maybe we should add one OBSOLETE
warning when the -M parameter is used). Thanks,
--
Peter Xu
- Re: [Qemu-devel] [PATCH v6 06/10] migration: move only_migratable to MigrationState, (continued)
[Qemu-devel] [PATCH v6 10/10] migration: hmp: dump globals, Peter Xu, 2017/06/27
[Qemu-devel] [PATCH v6 11/10] migration: add comment for TYPE_MIGRATE, Peter Xu, 2017/06/28