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,...
> > >
> > > Just merge my code mate.
> > > https://lore.kernel.org/r/[email protected]
> >
> > 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.
Ah OK, sure, will do when respin.
>
> > > - 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
Thanks,
--
Peter Xu
