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/[email protected]/ > > > 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
