From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36744 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P0ccZ-0006JZ-UG
	for qemu-devel@nongnu.org; Tue, 28 Sep 2010 12:01:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1P0ccT-0006j1-RO
	for qemu-devel@nongnu.org; Tue, 28 Sep 2010 12:01:35 -0400
Received: from mail-qy0-f180.google.com ([209.85.216.180]:49039)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1P0ccT-0006ip-If
	for qemu-devel@nongnu.org; Tue, 28 Sep 2010 12:01:29 -0400
Received: by qyk5 with SMTP id 5so10270464qyk.4
	for <qemu-devel@nongnu.org>; Tue, 28 Sep 2010 09:01:28 -0700 (PDT)
Message-ID: <4CA2115A.8030005@codemonkey.ws>
Date: Tue, 28 Sep 2010 11:01:30 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1285686097-13036-1-git-send-email-anthony.perard@citrix.com>
	<1285686097-13036-11-git-send-email-anthony.perard@citrix.com>
	<4CA2064A.7020701@codemonkey.ws>
	<alpine.DEB.2.00.1009281616350.2864@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1009281616350.2864@kaball-desktop>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 09/28/2010 10:25 AM, Stefano Stabellini wrote:
> On Tue, 28 Sep 2010, Anthony Liguori wrote:
>    
>> On 09/28/2010 10:01 AM, anthony.perard@citrix.com wrote:
>>      
>>> From: Anthony PERARD<anthony.perard@citrix.com>
>>>
>>> This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
>>> a call to qemu_ram_ptr_unlock, the pointer may be unmap from QEMU when
>>> used with Xen.
>>>
>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>>>
>>>        
>> Why isn't hooking cpu_physical_memory_{map,unmap}() not enough?  That's
>> really the intention of the API.
>>
>> You only really care about guest RAM, not device memory, correct?
>>      
> Yes, however at the moment all the calls to qemu_get_ram_ptr imply the
> mapping in qemu address space to remain valid for an unlimited amount of
> time.
>    

Yes, but qemu_get_ram_ptr() is not a general purpose API.  It really 
should only have one use--within exec.c to implement 
cpu_physical_memory_* functions.  There are a few uses in hw/* but 
they're all wrong and should be removed.  Fortunately, for the purposes 
of the Xen machine, almost none of them actually matter.

What I'm thinking is that RAM in Xen should not be backed at all from a 
RAMBlock.  Instead, cpu_physical_memory_* functions should call an 
explicit map/unmap() function that can be implemented as 
qemu_get_ram_ptr() and a nop in the TCG/KVM case and as explicit map 
cache operations in the Xen case.

Regards,

Anthony Liguori

> While we can do that because now the mapcache allows to "lock" a
> mapping, it would be nice if an explicit qemu_ram_ptr_unlock would be
> provided. It is not required for xen support though.
>
>
>