summaryrefslogtreecommitdiff
path: root/libkvm/libkvm.h
diff options
context:
space:
mode:
authorGlauber Costa <glommer@redhat.com>2008-09-23 14:44:34 -0300
committerAvi Kivity <avi@redhat.com>2008-09-24 14:48:51 +0300
commiteb22598d5809348a7f16d519a21ecba303af3804 (patch)
tree1f2277b8739eb27952925f073815b5e444584bbe /libkvm/libkvm.h
parentf0754cb1c1ce7be72d4fa48b67cfd5daf6601301 (diff)
kvm: libkvm: do not use mem_hole anymore.
memory holes are totally evil. Right now they work for some basic tests, but had never been stressed enough. Using memory holes leaves open questions like: * what happens if a area being registered span two slots? * what happens if there is already data in the slots? also, the code behaves badly if the piece to be removed lies in the boundaries of the current slot. Luckily, we don't really need it. Remove it, and make sure we never hit it. Signed-off-by: Glauber Costa <glommer@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
Diffstat (limited to 'libkvm/libkvm.h')
-rw-r--r--libkvm/libkvm.h2
1 files changed, 0 insertions, 2 deletions
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 79dd7698..77fd903f 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -457,8 +457,6 @@ void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start,
int kvm_is_intersecting_mem(kvm_context_t kvm, unsigned long phys_start);
int kvm_is_allocated_mem(kvm_context_t kvm, unsigned long phys_start,
unsigned long len);
-int kvm_create_mem_hole(kvm_context_t kvm, unsigned long phys_start,
- unsigned long len);
int kvm_register_phys_mem(kvm_context_t kvm,
unsigned long phys_start, void *userspace_addr,
unsigned long len, int log);