[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |