Re: [PATCH RFC 1/2] migration/vl: Allow set parameters with -incoming config:*

[Peter Xu <peterx@redhat.com>]

On Thu, Jun 04, 2026 at 10:21:45AM +0100, Mark Cave-Ayland wrote:
> On 03/06/2026 16:55, Peter Xu wrote:
> 
> > On Wed, Jun 03, 2026 at 04:36:37PM +0100, Mark Cave-Ayland wrote:
> > > Is the longer-term goal here to allow machine-versioned usage of all
> > > migration parameters supplied via -incoming via -global?
> > 
> > Nop.
> > 
> > Machine compat properties sticks with machines, they'll be applied properly
> > to migration objects at some point (needs to happen after machine object is
> > initialized).  It'll keep working, no plan to change that.
> 
> What are the machine compat properties currently being used for in this
> case? Presumably something that isn't expressed through a capability?

Please refer to:

https://lore.kernel.org/qemu-devel/ahmiKxc0swrIJQVB@x1.local/

> 
> > This series is only about exposing a new API to setup migration parameters
> > so that modules (like TAP as backends) can query at very early stage of
> > QEMU boot.
> 
> So shouldn't we just QOMify MigrationParameters so that our existing parser
> can be used without coming up with a custom solution? I feel I'm missing
> something obvious here since this was Fabiano's suggestion.

IIUC this series almost does it, qobject_input_visitor_new_str() and then
visit with a follow up visit_type_MigrationParameters().

Do we explicitly need to make it a separate TYPE_OBJECT?  Is there any
benefit of it, and how that proposal differs from the current?

Thanks,

-- 
Peter Xu