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