Peter Xu <[email protected]> writes: > On Wed, Jun 03, 2026 at 06:15:57PM +0100, Daniel P. Berrangé wrote: >> On Wed, Jun 03, 2026 at 11:50:53AM -0400, Peter Xu wrote: >> > On Wed, Jun 03, 2026 at 10:48:54AM +0100, Daniel P. Berrangé wrote: >> > > 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 <[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,... >> >> snip >> >> > > > > - 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. >> > >> > Yes, it's not elegant. I wished we had something like this though when >> > introducing the cpr channels; right now anything wasn't "defer" or URI >> > implies it's a "channel".. >> > >> > I also wanted to avoid introducing new cmdline parameters, so migration >> > incoming cmdlines can stick with the same option. If there's better >> > suggestion please shoot. >> > >> > > >> > > Does "-incoming config" imply '-incoming defer' semantics or is it >> > > independent ? >> > >> > They're independent. Examples: >> > >> > a) "-incoming config:* -incoming tcp:*", setup parameters for TCP incoming >> > migration without further deferral >> > >> > b) "-incoming config:*" only, setup global parameters for a possible >> > upcoming outgoing migration >> >> In that case they should definitely be independent command line >> options. The old "-incoming" design is already broken / limited >> in the non-'defer' case because it is hardcoded to use URI syntax >> which can't express all the address formats we accept in QAPI >> syntax. Adding more special cases onto -incoming just makes the >> bad situation even worse and is not a forward looking design. >> >> If we need the ability to specify migration parameters on the >> CLI, then as a starting point for the design, we should assume that >> -incoming does not exist, and design a complete solution from scratch >> that uses QAPI exclusively, both for addresses and configuration. > > Do we want to obsolete -incoming? > >> >> As discussed before, IMHO the "migrate" and "migrate-incoming" >> commands need to accept both the address(s) and parameters/capabilities >> as inline data items rather than relying on pre-configured global state >> from the 'migrate-parameter' / 'migrate-capability' commands. > > This is one example that "relying only on migrate/migrate-incoming to > specify parameters" won't work. > > Essentially parameters like CPR's and the new "local" parameter wants to be > global so that it will be visible and will have an impact on how other QEMU > modules behave. Here for TAP when "local" is globally on we may want to > initialize the device differently from the default operations. That will > need to happen before any QMP commands. > >> >> If we did that modelling for 'migrate-incoming' then that modelling of >> command parmaeters could map directly to a new '-migrate-incoming' >> command line argument that accepted exactly the same data model. > > This is true. Then we will make this series to depend on Fabiano's > previous work (to be posted; per we talked yesterday). >
I don't see the dependency. Take the 'config' out from this series and pass a JSON into -incoming. It can be parsed into MigrationParameters all the same. > I wanted to see if we can reduce the impact to minimum, -incoming is indeed > not well designed, but in real life we have control over what can happen > with URIs and the current "config:" won't conflict with any of them. > > But if we strongly wish to obsolete -incoming completely, I'm OK too. > > Thanks,
