This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.

To: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2010 16:25:08 +0100
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 28 Sep 2010 08:25:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CA2064A.7020701@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1285686097-13036-1-git-send-email-anthony.perard@xxxxxxxxxx> <1285686097-13036-11-git-send-email-anthony.perard@xxxxxxxxxx> <4CA2064A.7020701@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 28 Sep 2010, Anthony Liguori wrote:
> On 09/28/2010 10:01 AM, anthony.perard@xxxxxxxxxx wrote:
> > From: Anthony PERARD<anthony.perard@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> >    
> 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
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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>