From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M9KXS-0001FB-Vr
	for qemu-devel@nongnu.org; Wed, 27 May 2009 10:55:31 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M9KXO-0001Dx-7b
	for qemu-devel@nongnu.org; Wed, 27 May 2009 10:55:30 -0400
Received: from [199.232.76.173] (port=39745 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M9KXN-0001Di-UR
	for qemu-devel@nongnu.org; Wed, 27 May 2009 10:55:26 -0400
Received: from mx2.redhat.com ([66.187.237.31]:42453)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1M9KXM-0000NI-Do
	for qemu-devel@nongnu.org; Wed, 27 May 2009 10:55:25 -0400
Message-ID: <4A1D5437.7080300@redhat.com>
Date: Wed, 27 May 2009 17:54:47 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/3] Object-based physical memory management
References: <1243157375-14329-1-git-send-email-avi@redhat.com>
	<4A1D4965.2020309@us.ibm.com>
In-Reply-To: <4A1D4965.2020309@us.ibm.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: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Currently, qemu manages physical memory at a page granularity (and with
>> subpage, at a byte granularity).  This is expensive in memory and 
>> runtime
>> (requiring 8 bytes per page, and likely a cache miss on access), and is
>> difficult to manage: devices must remember their ranges so they can free
>> them, and the memory system has no insight into how memory is laid out.
>>
>> This patchset introduces object-based memory management.  The first 
>> patch
>> adds objects and functions for memory regions; the second patch wraps 
>> this
>> for PCI; and the third converts RTL8139 as an example.
>>   
>
> I like the basic notion here.  Instead of introducing the API and 
> converting one user, I'd rather do a flag day and convert everything.

I agree, just getting this out to collect feedback (and to undust this 
month-old branch).

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