Peter Xu <[email protected]> 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/[email protected] 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/[email protected] > > Especially, there're some context on this idea too in this email: > > https://lore.kernel.org/all/[email protected]/ > 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(-)
