[CRIU] [PATCH 2/2] lazy-pages: add support to combine pre-copy and post-copy

[Adrian Reber]

On Thu, Sep 08, 2016 at 10:16:37AM +0300, Mike Rapoport wrote:
> On Wed, Sep 07, 2016 at 06:24:32PM +0200, Adrian Reber wrote:
> > From: Adrian Reber <areber at redhat.com>
> > 
> > To combine pre-copy (pre-dump) and post-copy (lazy-pages) mode the
> > lazy-page mode must be made aware of pages which are only in the parent
> > image and not in the current checkpoint image.
> > 
> > As the restorer only works on VmaEntry-s and knows nothing about PageMap
> > entries the VmaEntry-s need to be adapted to match the PageMap entries.
> > 
> > This changes the lazy-page detection to not only rely on
> > vma_entry_can_be_lazy() but to also check if the page is available in
> > the parent. If the page is available in a parent checkpoint the page is
> > not marked as lazy via a new VmaEntry field (optional bool lazy = 11).
> > 
> > If the VmaEntry does not have the same size as the PageMap entry the
> > VmaEntry needs to be adapted to match the PageMap entry and then the new
> > lazy flag can be set in the VmaEntry.
> > 
> > The restorer then additionally has to check if the VmaEntry has the lazy
> > flag. If the lazy flag is not set, then the page is available in a
> > parent checkpoint.
> > 
> > This code additionally adds a 'return 0;' to unmap_guard_pages() as the
> > VmaEntry splitting can create multiple VmaEntry-s with MAP_GROWSDOWN and
> > only the first entry needs the guard page to be unmapped.
> 
> I believe, that restorer and lazy-pages daemon should switch to using
> pagemap for detection of memory areas that can be lazily restored. The
> pagemap entry should contain enough information about the actual location
> of the pages it describes. Then both restorer and lazy-pages daemon will
> not need VMA data to determine the way for restoring the pages.

I am not sure that is really possible. At least it looks like it
requires larger changes in the restorer. The restorer in criu/pie/ has
no knowledge about the PageMap and all the information about the to be
restored memory is in the VmaEntry-s. Information like PROT_READ,
PROT_EXEC, MAP_PRIVATE, MAP_ANON, VMA_AREA_VSYSCALL, VMA_ANON_PRIVATE, ...
Nothing of that is present in the PageMap. As I see it only the
VmaEntry-s know about that information and if page is in the parent or
not is in the PageMap. So I am not sure how the restorer can work on the
PageMap.

		Adrian