From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:44772)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony.perard@citrix.com>) id 1SrrhW-0005YT-Ve
	for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:27:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony.perard@citrix.com>) id 1SrrhV-0006L5-2C
	for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:27:34 -0400
Received: from smtp.citrix.com ([66.165.176.89]:32353)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony.perard@citrix.com>) id 1SrrhU-0006Kt-U8
	for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:27:32 -0400
Message-ID: <50081952.2080706@citrix.com>
Date: Thu, 19 Jul 2012 15:27:30 +0100
From: Anthony PERARD <anthony.perard@citrix.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>
	<50057A5E.1070602@redhat.com>
	<alpine.DEB.2.02.1207171927010.23783@kaball.uk.xensource.com>
	<5007F25E.4020502@citrix.com> <5007F473.8070301@redhat.com>
In-Reply-To: <5007F473.8070301@redhat.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
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: Avi Kivity <avi@redhat.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>

On 19/07/12 12:50, Avi Kivity wrote:
> On 07/19/2012 02:41 PM, Anthony PERARD wrote:
>> On 17/07/12 19:36, Stefano Stabellini wrote:
>>> On Tue, 17 Jul 2012, Avi Kivity wrote:
>>>> 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?
>>
>> I thought about it, but when I saw that set_dirty were called only when
>> it was not already set as dirty where the call seams to be necessary.
>>
>> I just try to call xen_modified_mem only within
>> cpu_phy_mem_set_dirty_flags but it does not work, even when I tried to
>> clear the dirtybits. But I maybe don't do the right thing yet to clear
>> the dirty bits
>
> You can wrap the if (not dirty) make_it_dirty() sequence in a helper,
> and insert your hypercall in the helper, unconditionally.

Ok, I'll do that.

Thanks,

-- 
Anthony PERARD