From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <005a01d1124e$de9dd610$9bd98230$@samsung.com> (Pavel Fedin's
	message of "Thu, 29 Oct 2015 16:36:51 +0300")
References: <012c01d110a6$cd61cf90$68256eb0$@samsung.com>
	<87k2q8e8d4.fsf@neno.neno>
	<002b01d110c0$4a5c8e40$df15aac0$@samsung.com>
	<877fm7b9h2.fsf@neno.neno>
	<007101d11174$ef2b83e0$cd828ba0$@samsung.com>
	<871tcdq31p.fsf@neno.neno>
	<005a01d1124e$de9dd610$9bd98230$@samsung.com>
Date: Thu, 29 Oct 2015 15:37:51 +0100
Message-ID: <87fv0toi4g.fsf@neno.neno>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel]
	[PATCH]	migration:	Introduce	migration_in_completion()
Reply-To: quintela@redhat.com
To: Pavel Fedin <p.fedin@samsung.com>
Cc: 'Amit Shah' <amit.shah@redhat.com>, 'Luiz Capitulino' <lcapitulino@redhat.com>, qemu-devel@nongnu.org, 'Michael Tsirkin' <mst@redhat.com>

Pavel Fedin <p.fedin@samsung.com> wrote:
>  Hello!
>
>> ok, your problem here is that you modify ram.  Could you take a look at
>> how vhost manage this?  It is done at migration_bitmap_sync(), and it
>> just marks the pages that are dirty.
>
>  Hm, interesting... I see it hooks into
> memory_region_sync_dirty_bitmap(). Sorry for maybe lame question, i do
> not know the whole
> code, and it will be much faster for you to explain it to me, than for
> me to dig into it myself. At what moment is it called during
> migration?

when we call migration_bitmap_sync() we end calling all the
MEMORY_LISTENERS registered, and they can do whatever they want, like
modifying RAM, syncronize tables, whatever.

>
>  For you to better understand what is necessary... ITS is a thing
> which can be implemented in-kernel by KVM, and i work on exactly
> this. In my implementation i add an ioctl, which is called after CPUs
> are stopped. It flushes internal caches of the vITS to the
> RAM. It happens inside the kernel. I guess, dirty state tracking works
> correctly in this case, because memory gets modified by the
> kernel, and i guess from qemu's point of view it's the same as memory
> being modified by the guest. Therefore, i do not need to
> modify memory state bitmaps. I only need to tell the kernel to
> actually write out the data.
>  If we talk about making this thing iterative, we anyway need this
> ioctl. It could be modified inside the kernel to update only
> those RAM parts whose data have been modified since the last
> flush. The semantics would stay the same - it's just an ioctl telling
> the virtual device to store its data in RAM.
>  Ah, and again, these memory listeners are not prioritized too. I
> guess i could use them, but i would need a guarantee that my
> listener is called before KVMMemoryListener, which picks up changes.

Wait a bit to see if Michael answer as how it is done for vhost.
I don't remember the details O:-)


What you really need is a call before we do the completion stage for
RAM.  Thinking about how to do this, and if there are other users.

Thanks, Juan.