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

Peter Xu posted 2 patches 1 day, 19 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260528212912.367967-1-peterx@redhat.com
Maintainers: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>, Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, Mark Kanda <mark.kanda@oracle.com>, Ben Chaney <bchaney@akamai.com>, Paolo Bonzini <pbonzini@redhat.com>
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(-)
[PATCH v2 0/2] migration/vl: new -incoming config:* for early migration parameters
Posted by Peter Xu 1 day, 19 hours ago
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
Re: [PATCH v2 0/2] migration/vl: new -incoming config:* for early migration parameters
Posted by Peter Xu 1 day, 19 hours ago
This should have RFC tag, and shouldn't be v2...  please ignore, sorry.

-- 
Peter Xu