From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59863)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Sr91N-00023i-Ul
	for qemu-devel@nongnu.org; Tue, 17 Jul 2012 10:45:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Sr91I-0007zt-1z
	for qemu-devel@nongnu.org; Tue, 17 Jul 2012 10:45:05 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49826)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Sr91H-0007zf-Py
	for qemu-devel@nongnu.org; Tue, 17 Jul 2012 10:44:59 -0400
Message-ID: <50057A5E.1070602@redhat.com>
Date: Tue, 17 Jul 2012 17:44:46 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
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>
In-Reply-To: <50056FAB.8030404@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 3/4] exec,
	memory: Call to xen_modified_memory.
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: Luiz Capitulino <lcapitulino@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>

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?

>> (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?

-- 
error compiling committee.c: too many arguments to function