On 07/20/2017 11:42 AM, Peter Maydell wrote:
On 17 July 2017 at 19:58, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote:
* Edgar E. Iglesias (edgar.igles...@gmail.com) wrote:
Is there a way we can prevent migration of the RAMBlock?
Not yet, I think we'd have to:
a) Add a flag to the RAMBlock
b) Set it/clear it on registration
c) Have a RAMBLOCK_FOREACH_MIGRATABLE macro
d) Replace all of the RAMBLOCK_FOREACH (and the couple of hand coded
cases) with the RAMBLOCK_FOREACH_MIGRATABLE
e) Worry about the corner cases!
I've got a few worries about what happens when the kernel tries to
do dirty yncing - I'm not sure if we have to change anything on that
interface to skip those RAMBlocks.
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?)
I do think we definitely need to fix this for 2.11 at latest.
I think we take less risks with the second one.
Maybe there is other problematic devices which don't call
vmstate_register_ram'd? Which would be broken by the first?
BTW the issue will show up only if ones execute code from the
LQSPI so maybe a mix between (3) and (2) ?
Fred
thanks
-- PMM
