From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:54002)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SsFR5-0001pq-F7
	for qemu-devel@nongnu.org; Fri, 20 Jul 2012 11:48:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SsFR1-00037O-2F
	for qemu-devel@nongnu.org; Fri, 20 Jul 2012 11:48:11 -0400
Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:35392
	helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SsFR0-00036r-T0
	for qemu-devel@nongnu.org; Fri, 20 Jul 2012 11:48:07 -0400
Date: Fri, 20 Jul 2012 16:47:16 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <5009670F.1000209@citrix.com>
Message-ID: <alpine.DEB.2.02.1207201646150.26163@kaball.uk.xensource.com>
References: <1342531805-29894-1-git-send-email-anthony.perard@citrix.com>
	<1342531805-29894-5-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.02.1207171907580.23783@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1207171929150.23783@kaball.uk.xensource.com>
	<5009670F.1000209@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: [Qemu-devel] [PATCH 4/4] xen: Always set the vram dirty during
	migration.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, QEMU-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>, Avi Kivity <avi@redhat.com>, Xen Devel <xen-devel@lists.xen.org>

On Fri, 20 Jul 2012, Anthony PERARD wrote:
> On 17/07/12 19:30, Stefano Stabellini wrote:
> > On Tue, 17 Jul 2012, Stefano Stabellini wrote:
> >> On Tue, 17 Jul 2012, Anthony PERARD wrote:
> >>> Because the call to track the dirty bit in the video ram during migration won't
> >>> work (it returns -1), we set dirtybit on the all video ram.
> >>>
> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >>> ---
> >>>   xen-all.c |    5 +++++
> >>>   1 files changed, 5 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/xen-all.c b/xen-all.c
> >>> index 498883b..00bdb50 100644
> >>> --- a/xen-all.c
> >>> +++ b/xen-all.c
> >>> @@ -502,6 +502,11 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
> >>>           return;
> >>>       }
> >>>
> >>> +    if (unlikely(xen_in_migration)) {
> >>> +        /* track_dirty_vram does not work during migration */
> >>> +        memory_region_set_dirty(framebuffer, 0, size);
> >>> +        return;
> >>> +    }
> >>>       rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
> >>>                                    start_addr >> TARGET_PAGE_BITS, npages,
> >>>                                    bitmap);
> >>
> >> Why are you setting the entire framebuffer dirty?
> >> We should set dirty only the actualy region that is supposed to be
> >> dirty.
> 
> I set the dirty bit on the all framebuffer because the track dirty call 
> fail, so I don't which bits are dirty. This one is for QEMU to know 
> which part of the screen need to be updated.

In that case it would be better to set the entire bitmap to 0xff in case
xc_hvm_track_dirty_vram fails, right?
So that we don't need to special case live migration.