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: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2010 11:01:30 -0500
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Tue, 28 Sep 2010 09:03:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1009281616350.2864@kaball-desktop>
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> <alpine.DEB.2.00.1009281616350.2864@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7
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@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

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.


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.

Xen-devel mailing list

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