Re: [PATCH RFC 1/2] migration/vl: Allow set parameters with -incoming config:*

[Peter Xu <peterx@redhat.com>]

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