On Thu, Jun 04, 2026 at 11:00:17AM +0100, Mark Cave-Ayland wrote: > On 03/06/2026 16:59, Peter Xu wrote: > > > > Is this part of the same problem in that the migration object needs to be > > > created much earlier than it is currently? And could doing this > > > potentially remove the need for a separate CPR channel? > > > > The problem is the migration object can't yet be created too early, due to > > the fact it needs to apply compat properties. That's why this series used > > another approach to have a temporary early MigrationParameters object to > > keep things until migration object is initialized (during which the temp > > object will be destroyed). > > If the MigrationParameters are needed earlier, then presumably devices can > only depend upon the value of migration capabilities, and not the value of > migration compat props? > > In that case could you not just build the migration compat props with > .realized_set_allowed = true in a similar way to e.g. hw/nvram/xlnx-bbram.c?
Could you elaborate? A few contexts to provide: Migration object (even if now a TYPE_DEVICE) doesn't use realize(), and it will be TYPE_OBJECT soon, which is at least the current plan. Direct use of anything qdev specific won't work. The other thing is, migration parameters by default should be allowed to be set anytime after QEMU starts but before migration starts. I don't yet understand the reference of realized_set_allowed use case, and how that idea can apply to migration. Thanks, -- Peter Xu
