From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NWu61-0002mA-CL
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:04:53 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NWu5w-0002jv-90
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:04:52 -0500
Received: from [199.232.76.173] (port=37081 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NWu5v-0002jp-Uf
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:04:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:19774)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NWu5u-0007xa-26
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:04:47 -0500
Message-ID: <4B548698.9050402@redhat.com>
Date: Mon, 18 Jan 2010 18:04:40 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers
References: <cover.1262634464.git.mst@redhat.com>
	<20100104194904.GB21299@redhat.com> <4B545C03.40807@redhat.com>
	<20100118135234.GC8317@redhat.com> <4B54691B.7090601@redhat.com>
	<20100118144456.GD8317@redhat.com> <4B54759A.1030208@redhat.com>
	<20100118154510.GA14828@redhat.com>
In-Reply-To: <20100118154510.GA14828@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: gleb@redhat.com, qemu-devel@nongnu.org

On 01/18/2010 05:45 PM, Michael S. Tsirkin wrote:
>
> cpu_register_physical_memory_offset already is O(memory size) btw.
>    

Right, but we'd like to replace it with a range API.

>    
>>>> Maybe we mandate clients be registered at init-time?
>>>>
>>>>          
>>> This might be tricky - vhost currently only registers when the
>>> first device is hot-added.
>>>
>>>        
>> I see.
>>
>> Maybe coalesce adjacent pages and call the callback with the ranges?
>>      
> Hmm, it turns out to be tricky: it seems whether we can do this
> really depends on what get_ram_ptr returns ...
> Can't we just rely on callback to do the coalescing?
>    

If the callback can do the coalescing, surely the caller can as well?

This way we don't introduce a new per-page API.

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