Commit Graph

9 Commits

Author SHA1 Message Date
Anthony Liguori
7267c0947d Use glib memory allocation and free functions
qemu_malloc/qemu_free no longer exist after this commit.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-20 23:01:08 -05:00
Stefan Berger
ecf169b7fa Fix a compilation error in xen-mapcache.c
This patch fixes a compilation error in xen-mapcache.c .

/home/stefanb/qemu/qemu-git/xen-mapcache.c: In function ‘xen_ram_addr_from_mapcache’:
/home/stefanb/qemu/qemu-git/xen-mapcache.c:240:42: error: variable ‘pentry’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-29 09:33:56 -05:00
Jan Kiszka
e41d7c691a xen: Clean up map cache API naming
The map cache is a Xen thing, so its API should make this clear.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-07-17 01:54:24 +02:00
Stefano Stabellini
6506e4f995 xen: remove xen_map_block and xen_unmap_block
Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-19 04:40:05 +02:00
Stefano Stabellini
cd306087e5 xen: remove qemu_map_cache_unlock
There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-19 04:40:04 +02:00
Stefano Stabellini
c13390cd38 xen: fix qemu_map_cache with size != MCACHE_BUCKET_SIZE
Fix the implementation of qemu_map_cache: correctly support size
arguments different from 0 or MCACHE_BUCKET_SIZE.
The new implementation supports locked mapcache entries with size
multiple of MCACHE_BUCKET_SIZE. qemu_invalidate_entry can correctly
find and unmap these "large" mapcache entries given that the virtual
address passed to qemu_invalidate_entry is the same returned by
qemu_map_cache when the locked mapcache entry was created.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-19 04:40:04 +02:00
Anthony PERARD
050a0ddf39 Introduce qemu_put_ram_ptr
This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
a call to qemu_put_ram_ptr, the pointer may be unmap from QEMU when
used with Xen.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-05-08 10:10:01 +02:00
John Baboval
ea6c5f8ffe xen: Adds a cap to the number of map cache entries.
Adds a cap to the number of map cache entries. This prevents the map
cache from overwhelming system memory.

I also removed the bitmap macros and #included bitmap.h instead.

Signed-off-By: John Baboval <john.baboval@virtualcomputer.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-05-08 10:10:01 +02:00
Jun Nakajima
432d268c05 xen: Introduce the Xen mapcache
On IA32 host or IA32 PAE host, at present, generally, we can't create
an HVM guest with more than 2G memory, because generally it's almost
impossible for Qemu to find a large enough and consecutive virtual
address space to map an HVM guest's whole physical address space.
The attached patch fixes this issue using dynamic mapping based on
little blocks of memory.

Each call to qemu_get_ram_ptr makes a call to qemu_map_cache with the
lock option, so mapcache will not unmap these ram_ptr.

Blocks that do not belong to the RAM, but usually to a device ROM or to
a framebuffer, are handled in a separate function. So the whole RAMBlock
can be map.

Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-05-08 10:10:01 +02:00