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,...

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/

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.

Thanks,

Peter Xu (2):
  migration/vl: Allow set parameters with -incoming config:*
  migration/cpr: Opt-in "mode" parameter for early boot access

 include/migration/cpr.h  |  3 --
 include/migration/misc.h |  5 +++
 migration/migration.h    |  3 ++
 migration/cpr.c          | 18 ++++----
 migration/migration.c    | 91 +++++++++++++++++++++++++++++++++++++++-
 migration/options.c      | 10 ++---
 system/vl.c              |  7 ++++
 qemu-options.hx          | 18 +++++++-
 8 files changed, 133 insertions(+), 22 deletions(-)

-- 
2.53.0

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

A couple of differences from my patch:

- old-style keyval vs. json;

Isn't json preferred nowadays?

- 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.

>
> 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.

> Thanks,
>
> Peter Xu (2):
>   migration/vl: Allow set parameters with -incoming config:*
>   migration/cpr: Opt-in "mode" parameter for early boot access
>
>  include/migration/cpr.h  |  3 --
>  include/migration/misc.h |  5 +++
>  migration/migration.h    |  3 ++
>  migration/cpr.c          | 18 ++++----
>  migration/migration.c    | 91 +++++++++++++++++++++++++++++++++++++++-
>  migration/options.c      | 10 ++---
>  system/vl.c              |  7 ++++
>  qemu-options.hx          | 18 +++++++-
>  8 files changed, 133 insertions(+), 22 deletions(-)

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..).

> 
> - 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.

> 
> >
> > 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