qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request
Date: Thu, 20 Jul 2017 10:42:09 +0100

On 17 July 2017 at 19:58, Dr. David Alan Gilbert <address@hidden> wrote:
> * Edgar E. Iglesias (address@hidden) 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.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]