On Fri, May 29, 2026 at 10:26:26AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 29.05.26 00:29, Peter Xu wrote:
> > QEMU doesn't yet have a good way to specify migration parameters so that
> > they can be available even during early stage of QEMU boots. It is because
> > the migration object (who owns the migration parameters) will only be
> > created after PHASE_LATE_BACKENDS_CREATED. It means anything before it
> > reading migration parameters is illegal.
>
> But with this series, we actually do create a part of this migration object,
> which is created earlier.
>
> Is it possible instead to initialize the whole migration object earlier?
> Or maybe, somehow "partly" initialize it (if full initialization is not
> possible for some reasons), but still keep one object, without external
> part, stored in separate global variable?
It needs to be there because migration object currently depends on machine
compat properties to apply some parameters on top, see:
$ git grep "\"migration\"" hw/core/machine.c
hw/core/machine.c: { "migration", "multifd-clean-tls-termination", "false" },
hw/core/machine.c: { "migration", "send-switchover-start", "off"},
hw/core/machine.c: { "migration", "zero-page-detection", "legacy"},
hw/core/machine.c: { "migration", "multifd-flush-after-each-section", "on"},
hw/core/machine.c: { "migration", "x-preempt-pre-7-2", "true" },
While machine compat properties are initialized in different phases. The
one we really depend on (per above) is qemu_create_machine(), where
object_set_machine_compat_props() updates object_compat_props[1].
Logically it's fully initialized after all three entries updated, which
means we'd better initialize migration objects after at least
configure_accelerators() which updates object_compat_props[2]..
--
Peter Xu
