On 20 July 2017 at 10:42, Peter Maydell <peter.mayd...@linaro.org> wrote: > OK, so what should we do for 2.10 ? > > We could: > * implement the changes you suggest above, and mark only > vmstate_register_ram'd blocks as migratable > (would probably need to fix some places which buggily > don't call vmstate_register_ram) > * implement the changes above, but special case mmio-interface > so only its ramblock is marked unmigratable > * postpone the changes above until 2.11, and for 2.10 register > a migration-blocker in mmio-interface so that we at least > give the user a useful error rather than having it fail > obscurely on vmload (and release note this) > > (Or something else?)
Talking to David about this on IRC, even "don't allow migration" is a bit tricky, because you can't register a migration-blocker if a migration is already in progress. Two further options: * disable this mmio-exec-in-place entirely for 2.10 as being not completely baked yet, and fix it properly in 2.11 * ditto, but allow the device to have an x-enable-exec-in-place property which turned on the not-baked feature (the property would go away in 2.11, which is OK because of the x- experimental prefix) I'm leaning towards disable-entirely at the moment... thanks -- PMM
