All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <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>
Subject: Re: [Qemu-devel] [PATCH]	migration:	Introduce	migration_in_completion()
Date: Thu, 29 Oct 2015 15:37:51 +0100	[thread overview]
Message-ID: <87fv0toi4g.fsf@neno.neno> (raw)
In-Reply-To: <005a01d1124e$de9dd610$9bd98230$@samsung.com> (Pavel Fedin's message of "Thu, 29 Oct 2015 16:36:51 +0300")

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.

      reply	other threads:[~2015-10-29 14:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27 11:01 [Qemu-devel] [PATCH] migration: Introduce migration_in_completion() Pavel Fedin
2015-10-27 13:41 ` Juan Quintela
2015-10-27 14:03   ` Pavel Fedin
2015-10-28  9:58     ` Juan Quintela
2015-10-28 10:27       ` Pavel Fedin
2015-10-28 11:36       ` Pavel Fedin
2015-10-29 12:20         ` Juan Quintela
2015-10-29 13:36           ` Pavel Fedin
2015-10-29 14:37             ` Juan Quintela [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fv0toi4g.fsf@neno.neno \
    --to=quintela@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mst@redhat.com \
    --cc=p.fedin@samsung.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.