From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [PATCH 3/4] exec,
 memory: Call to xen_modified_memory.
Date: Tue, 17 Jul 2012 19:36:45 +0100
Message-ID: <alpine.DEB.2.02.1207171927010.23783__33926.8215619542$1342550371$gmane$org@kaball.uk.xensource.com>
References: <1342531805-29894-1-git-send-email-anthony.perard@citrix.com>
	<1342531805-29894-4-git-send-email-anthony.perard@citrix.com>
	<50056AA1.9010004@redhat.com> <50056FAB.8030404@citrix.com>
	<50057A5E.1070602@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <50057A5E.1070602@redhat.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Avi Kivity <avi@redhat.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>, Anthony Perard <anthony.perard@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 17 Jul 2012, Avi Kivity wrote:
> On 07/17/2012 04:59 PM, Anthony PERARD wrote:
> >>
> >> This is pretty ugly.  An alternative is to set up a periodic bitmap scan
> >> that looks at the qemu dirty bitmap and calls xen_modified_memory() for
> >> dirty page ranges, and clears the bitmap for the next pass.  Is it
> >> workable?
> > 
> > I don't think a periodic scan can do anything useful, unfortunately.
> 
> Why not?

I vaguely remember that we used to have a bitmap years ago, but, aside from
making the code much more complicated, it caused blue screens on
intensive disk accesses.


> >> (is xen_modified_memory a hypercall, or does it maintain an in-memory
> >> structure?)
> > 
> > It's an hypercall. The function do something (call the hypercall) only
> > during migration, otherwise it return immediately.
> 
> I see.  I guess it isn't expensive for you because there isn't much dma
> done by qemu usually with xen (unlike kvm where pv block devices are
> implemented in qemu).
> 
> How about pushing the call into cpu_physical_memory_set_dirty_flags()?
> Would that reduce the number of call sites?

Pushing the calls to cpu_physical_memory_set_dirty_flags and
cpu_physical_memory_set_dirty_range would make the code much nicer.
However being these functions in exec-obsolete.h, are they at risk of
removal?