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

From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	KONRAD Frederic <frederic.konrad@adacore.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request
Date: Tue, 18 Jul 2017 15:53:59 +0100	[thread overview]
Message-ID: <20170718145358.GB2106@work-vm> (raw)
In-Reply-To: <CAFEAcA_HQFtNr82QqE0+j8_SUGm_8-1JLavBnXYTmRvTVb+vYQ@mail.gmail.com>

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 17 July 2017 at 19:58, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> > * Edgar E. Iglesias (edgar.iglesias@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.
> 
> Why would we need to skip those RAM blocks? We get correct
> behaviour whether the memory is sync'd with the kernel
> or not, because we're not going to migrate it anywhere.

We have to make sure the count of dirty pages doesn't include the dirty
pages from those blocks, or migration will never finish.

Dave

> thanks
> -- PMM
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK