[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.