From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LojGh-0003Nu-6j
	for qemu-devel@nongnu.org; Tue, 31 Mar 2009 15:05:03 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LojGc-0003Ng-Ha
	for qemu-devel@nongnu.org; Tue, 31 Mar 2009 15:05:02 -0400
Received: from [199.232.76.173] (port=46571 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LojGc-0003Nd-B9
	for qemu-devel@nongnu.org; Tue, 31 Mar 2009 15:04:58 -0400
Received: from mx2.redhat.com ([66.187.237.31]:32928)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <ykamay@redhat.com>) id 1LojGb-0006pQ-B2
	for qemu-devel@nongnu.org; Tue, 31 Mar 2009 15:04:58 -0400
Message-ID: <49D26954.2030801@redhat.com>
Date: Tue, 31 Mar 2009 22:04:52 +0300
From: Yaniv Kamay <ykamay@redhat.com>
MIME-Version: 1.0
References: <1238518275-2980-1-git-send-email-glommer@redhat.com>
	<1238518275-2980-2-git-send-email-glommer@redhat.com>
In-Reply-To: <1238518275-2980-2-git-send-email-glommer@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 1/3] stop dirty tracking just at the end of
	migration
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Glauber Costa <glommer@redhat.com>
Cc: aliguori@us.ibm.com, Dor Laor <dlaor@redhat.com>, qemu-devel@nongnu.org, avi@redhat.com

We need to update dirty map before ram_save_block() loop.

Glauber Costa wrote:
> If there is still work to do, it is not safe to assume we
> can end the dirty tracking. Specifically, kvm can update the dirty
> tracking log inside ram_save_block(), leaving pages still out of sync
> if we go with the current code.
>
> Based on a patch by Yaniv Kamay
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> CC: Yaniv Kamay <ykamay@redhat.com>
> CC: Dor Laor <dlaor@redhat.com>
> ---
>  vl.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 5e6c621..1626f8a 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3249,10 +3249,10 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
>      /* try transferring iterative blocks of memory */
>  
>      if (stage == 3) {
> -        cpu_physical_memory_set_dirty_tracking(0);
>  
>          /* flush all remaining blocks regardless of rate limiting */
>          while (ram_save_block(f) != 0);
> +        cpu_physical_memory_set_dirty_tracking(0);
>      }
>  
>      qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
>