[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request |
Date: |
Thu, 20 Jul 2017 11:02:32 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
* Peter Maydell (address@hidden) wrote:
> 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
I think either of these is too late for 2.10 - I don't fancy prodding
about in all of the migration RAM loops at this stage.
> * 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)
I think that's best, especially because I've just thought of another nasty.
If I understand the way mmio-interface is working, you're dynamically
changing the RAMBlock list while the guest is running.
And while we are using QLIST_FOREACH_RCU I'm not convinced we're
actually safe against dynamic modification of that list.
> (Or something else?)
>
> I do think we definitely need to fix this for 2.11 at latest.
OK, I can do a-e OK, I'm more worried now about that dynamic
modification I just thought of.
Dave
> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/17
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Edgar E. Iglesias, 2017/07/17
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/17
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/20
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/20
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Juan Quintela, 2017/07/27
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Juan Quintela, 2017/07/27
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/28