Re: [Qemu-devel] [PATCH v1 2/2] migration: add bitmap for copied page

[Alexey]

On Wed, Jun 14, 2017 at 05:29:39PM +0200, Juan Quintela wrote:
> Alexey Perevalov <address@hidden> wrote:
> > On 06/13/2017 02:42 PM, Juan Quintela wrote:
> >> Alexey Perevalov <address@hidden> wrote:
> >>
> >> Hi
> >>
> >> I think that it would make things clearer if we do a s/copied/received/
> >> As what we are tracking here are the pages that have already been
> >> received.
> >>
> >>
> >>> This patch adds ability to track down already copied
> >>> pages, it's necessary for calculation vCPU block time in
> >>> postcopy migration feature, maybe for restore after
> >>> postcopy migration failure.
> >>> Also it's necessary to solve shared memory issue in
> >>> postcopy livemigration. Information about copied pages
> >>> will be transferred to the software virtual bridge
> >>> (e.g. OVS-VSWITCHD), to avoid fallocate (unmap) for
> >>> already copied pages. fallocate syscall is required for
> >>> remmaped shared memory, due to remmaping itself blocks
> >>> ioctl(UFFDIO_COPY, ioctl in this case will end with EEXIT
> >>> error (struct page is exists after remmap).
> >>>
> >>> Bitmap is placed into RAMBlock as another postcopy/precopy
> >>> related bitmaps.
> >> Why are we not using the TARGET_PAGE_SIZE as units of the bitmap?
> >>
> >>
> >>> copied bitmap is not releasing due to ramblocks is not releasing
> >>> too.
> >> RAMBlocks are used for other reasons, not only migration.  This bitmaps
> >> can be released on the ram_load_cleanup() function.  See my patches on
> >> list about how to use it.
> > I saw patch "migration: Convert ram to use new load_setup()/load_cleanup()",
> > second version
> >
> > ram_load_cleanup - IIUC, calls as load_cleanup callback, from 2 use cases:
> >     1. QEMU_OPTION_loadvm
> >     2. hmp_loadvm
> >
> > in both cases: load_snapshot, qemu_loadvm_state,
> > qemu_loadvm_state_cleanup, load_cleanup callback
> 
> Hi
> 
> Are you looking at v2?
> 
Yes, I took v2.
> On my tree:
> 
> int qemu_loadvm_state(QEMUFile *f)
> {
> 
> ....
it presents, but listen thread still exists
and on mis->have_listen_thread condition we're returning
from qemu_loadvm_state, before qemu_loadvm_state_cleanup invocation.
> 
>     qemu_loadvm_state_cleanup();
>     cpu_synchronize_all_post_init();
> 
>     return ret;
> }
> 
> And everything that counts call qemu_loadvm_state() to load the state,
> no?
yes, in my case qemu_loadvm_state is calling.
> 
> Later, Juan.
> 

-- 

BR
Alexey