From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NWuCe-0004Jw-BS
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:11:44 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NWuCY-0004JP-TZ
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:11:43 -0500
Received: from [199.232.76.173] (port=58952 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NWuCY-0004JM-Lg
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:11:38 -0500
Received: from mx1.redhat.com ([209.132.183.28]:51371)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1NWuCY-0000K7-6B
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 11:11:38 -0500
Date: Mon, 18 Jan 2010 18:08:33 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers
Message-ID: <20100118160833.GC14828@redhat.com>
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> <4B548698.9050402@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B548698.9050402@redhat.com>
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: Avi Kivity <avi@redhat.com>
Cc: gleb@redhat.com, qemu-devel@nongnu.org

On Mon, Jan 18, 2010 at 06:04:40PM +0200, Avi Kivity wrote:
> 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.

So, when we do the implementation of notifiers can follow?

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

The callback calls qemu_ram_ptr and coalesces when the virtual memory
pointers are matching. caller can do this as well but it looks ugly: we
don't know this is what caller does ...

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

What do you mean by new per-page API?
The API is range-based, implementation
currently scans all pages.

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