On Mon, Jun 26, 2017 at 10:50:35AM +0800, Peter Xu wrote: > On Fri, Jun 23, 2017 at 07:18:19PM -0300, Eduardo Habkost wrote: > > On Fri, Jun 23, 2017 at 12:46:40PM +0800, Peter Xu wrote: > > > Let the old man "MigrationState" join the object family. Direct benefit > > > is that we can start to use all the property features derived from > > > current QDev, like: HW_COMPAT_* bits, command line setup for migration > > > parameters (so will never need to set them up each time using HMP/QMP, > > > this is really, really attractive for test writters), etc. > > > > > > I see no reason to disallow this happen yet. So let's start from this > > > one, to see whether it would be anything good. > > > > > > Now we init the MigrationState struct statically in main() to make sure > > > it's initialized after global properties are applied, since we'll use > > > them during creation of the object. > > > > > > No functional change at all. > > > > > > Reviewed-by: Juan Quintela <quint...@redhat.com> > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > > --- > > > include/migration/misc.h | 1 + > > > migration/migration.c | 78 > > > ++++++++++++++++++++++++++++++++++-------------- > > > migration/migration.h | 19 ++++++++++++ > > > vl.c | 6 ++++ > > > 4 files changed, 81 insertions(+), 23 deletions(-) > > > > > [...] > > > diff --git a/vl.c b/vl.c > > > index cdd2ec8..9b04ba7 100644 > > > --- a/vl.c > > > +++ b/vl.c > > > @@ -4596,6 +4596,12 @@ int main(int argc, char **argv, char **envp) > > > */ > > > register_global_properties(current_machine); > > > > > > + /* > > > + * Migration object can only be created after global properties > > > + * are applied correctly. > > > + */ > > > + migration_object_init(); > > > + > > > > Do we really need this? Can't be we just do: > > > > if (!current_migration) { > > current_migration = MIGRATION_OBJ(object_new(TYPE_MIGRATION)); > > } > > > > inside migration_get_current()? > > I did this change on purpose (after AccelClass.global_props is > introduced). The comment above tried to explain it but looks like it's > still not clear enough... The reason is that currently the creation of > migration object is depending on the global properties, so we need to > create the object after register_global_properties(), while the old > migrate_get_current() cannot really be sure of this ordering: it just > creates the object on the first call of the function, but the first > call can be even before register_global_properties(). If so, we'll > have a problem (e.g. Xen compat properties will be missing). > > Now this restriction is strictly followed if we create the migrate > object here. If anyone calls migrate_get_current() before > register_global_properties(), there will be an assert, and that should > be treated as a programming error.
Makes sense to me. Thanks! -- Eduardo