Re: [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, May 29, 2026 at 10:15:35AM -0400, Peter Xu wrote:
> On Thu, May 28, 2026 at 07:01:50PM -0300, Fabiano Rosas wrote:
> > Peter Xu <peterx@redhat.com> writes:
> > 
> > > CI: https://gitlab.com/peterx/qemu/-/pipelines/2560168907
> > >
> > > This series introduces a generic way to specify migration parameters that
> > > can be used even during the early boot phase of QEMU.
> > >
> > > One example use case that already existed is CPR-transfer / CPR-exec.
> > > currently QEMU has a temporary global variable (incoming_mode) to achieve
> > > this, but it's hard to understand and this hack bleeded into quite a few
> > > places that we could have avoided.  The lines in patch 2 touched may
> > > provide some idea.
> > >
> > > With a generic approach of setting migration parameters with cmdlines, we
> > > can remove this hack meanwhile QEMU should be able to keep the CPR behavior
> > > as before.  To CPR maintainers and reviewers: please have a closer look,
> > > even better if it can be smoke tested, to see if this works for Oracle's
> > > environment, TIA.
> > >
> > > The 1st patch implemented that new semantics.  It is straightforward: now
> > > we can setup any migration parameter using an extra line of:
> > >
> > >   -incoming config:key1=value1,key2=value2,...
> > 
> > Just merge my code mate.
> > https://lore.kernel.org/r/20251215220041.12657-25-farosas@suse.de
> 
> Heh, I apologize. I totally forgot it even if I seem to have read it..
> 
> The goal is differnent, though, which is to make it available before
> migration object initialization.  Say, I wished -global would work too but
> it doesn't, and it just can't.  So it's not "something good to have"
> anymore, but functionally required for either CPR and TAP in the future if
> we adopt this, they'll all read them early.
> 
> > 
> > A couple of differences from my patch:
> > 
> > - old-style keyval vs. json;
> > 
> > Isn't json preferred nowadays?
> 
> I didn't mention it in doc, but yeah this series also supports JSON due to
> the same qapi helper used.  I don't suggest json though for this entry (and
> that's also why I didn't mention it..) because 99% of migration parameters
> are scalars and I don't see why we should use JSON here.. the only one not
> scalar is block-bitmap-mapping but it's not intended to be used in
> -incoming at all (even if it'll work..).

99% of **todays** parameters are scalars.

The reason we are actively moving to CLI args which are modelled with QAPI
and expressable using JSON is because that future proofs the command line
for any kind of parameters we might need.

We should actively document and promote the use of JSON.

> > - using "config:"
> > 
> > This makes it non-uniform with uri and channels which don't have a
> > keyword in front of them. I guess I could live with it, but it seems
> > odd. I see that it makes parsing way easier.
> 
> Yeah, having some identifier would be nice.  I wished channels also have
> identifiers if we don't need to keep compatibility.

IMHO having a magic "config:" prefix is an anti-pattern because it
involves custom command line parsing logic.

Does "-incoming config" imply '-incoming defer' semantics or is it
independent ?  



> 
> > 
> > >
> > > So far only one such instance is allowed for simplicity, but it should be
> > > enough.  We still allow multiple -incoming for specifying channels, used
> > > together with one "-incoming config:*".
> > >
> > > Then parameters set this way will be visible almost anytime for QEMU, for
> > > example, during initialization of device backends (which is before
> > > migration object created).
> > >
> > > I posted this series majorly because I want to see if this will make a
> > > possible new user for the new "local" migration parameter proposed in
> > > Vladimir's series:
> > >
> > >   https://lore.kernel.org/r/20260522120534.77653-1-vsementsov@yandex-team.ru
> > >
> > > Especially, there're some context on this idea too in this email:
> > >
> > >   https://lore.kernel.org/all/ahdI7Vl5KraK566D@x1.local/
> > >
> > 
> > I like the idea overall.
> > 
> > > With this series, we should be able to drop "incoming-fds" TAP property
> > > from the other series, instead relying on the existing "local" parameters
> > > both in migration core and in TAP's property should suffice.
> > >
> > > One thing to mention is I didn't further make only-migratable into a
> > > migration parameter.  Logically it will also work now with only-migratable,
> > > but it then also means I'll need to convert it to a parameter, which will
> > > be mutable even after VM started.  It will change how only-migratable used
> > > to work, hence I skipped.
> > >
> > > After this, we also almost have no reason to use -global for migration
> > > parameters.  Capabilities are still not supported in -incoming cmdline,
> > > though.
> > >
> > 
> > Will we still merge capabilities and parameters? Then it would be a free
> > upgrade.
> 
> Yes!  /me waiting for your patches.
> 
> -- 
> Peter Xu
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|