On Wed, Nov 19, 2014 at 03:18:01PM +0100, Juan Quintela wrote: > Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 19 November 2014 14:07, Juan Quintela <quint...@redhat.com> wrote: > >> My understanding is that it is a "trick". We have internal memory for a > >> device that is needed for the emulation, but not showed to the guest. > >> And it is big enough that we want to save it during the "live" stage of > >> migration, so we mark it as RAM. if it is somekind of cash, we can just > >> enlarge it on destination, and it don't matter. If this has anything > >> different on the other part of the RAM, we are on trouble. > > > > Would it be feasible to just have the migration code provide > > an API for registering things to be migrated in the live > > migration stage, rather than creating memory regions which > > you can't actually use for most of the purposes the memory > > region API exists for? > > If somebody told me what they need, we can do it. > > Stefan, you needed something like that for data-plane? Or that memory > is mapped on the guest?
No, dataplane has no special requirements here. I am working on making the dirty memory bitmap atomic so that dataplane threads can dirty memory at the same time as other threads. But that's a different topic from what you are discussing here. Stefan
pgp2GfGWCGKft.pgp
Description: PGP signature
