|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.
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
time.
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|