From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm <kvm@vger.kernel.org>, Hollis Blanchard <hollisb@us.ibm.com>,
Carsten Otte <cotte@de.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH] kvm: work around inability of older kvm modules to destroy memory regions
Date: Wed, 17 Dec 2008 14:09:28 +0100 [thread overview]
Message-ID: <4948FA08.8010505@linux.vnet.ibm.com> (raw)
In-Reply-To: <4948EFEC.2020407@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Avi Kivity wrote:
> Christian Ehrhardt wrote:
>> Hi, this patch breaks all non x86 architectures as
>> libkvm/libkvm-x86.c has the only implementation of the alias
>> functionality.
>> Until now only qemu-kvm-x86 has called that functions, but since this
>> patch the generic qemu-kvm.c calls them which leads to unresolved
>> symbols for powerpc, s390 and surely ia64 too.
>>
>> Well we could insert stubs for these call, but when looking on the
>> kernel side x86 is also the only implementer of the
>> KVM_SET_MEMORY_ALIAS ioctl. Until more arch support that there is no
>> reason to create these functions for non-x86 in libkvm. Also the
>> assumptions which addresses must be aliased base on hardware specific
>> assumptions e.g. vga card -> arch specific too.
>>
>> For now I hold a no-op stub in my private queue to test powerpc, but
>> eventually this mechanism should be arch dependent and this
>> implementation x86 only.
>> Avi could you modify your patch to work for the other arch's too ?
>
> Your band aid should be fine. Yes, it's ugly, but this will be in
> flux as we merge with upstream qemu. Please resend it with a signoff.
>
still ugly, but in a proper patch style now :-)
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
[-- Attachment #2: memory-aliases.diff --]
[-- Type: text/x-diff, Size: 3979 bytes --]
Subject: [PATCH] kvm-userspace: guard destroy memory regions to x86 only
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Some parts of the changes made were arch specific e..g vga mem.
This is a quick, but ugly workaround until a real arch split is found.
Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---
[diffstat]
qemu-kvm.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
[diff]
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -766,7 +766,9 @@ int kvm_qemu_init()
return 0;
}
+#ifdef TARGET_I386
static int destroy_region_works = 0;
+#endif
int kvm_qemu_create_context(void)
{
@@ -784,7 +786,9 @@ int kvm_qemu_create_context(void)
r = kvm_arch_qemu_create_context();
if(r <0)
kvm_qemu_destroy();
+#ifdef TARGET_I386
destroy_region_works = kvm_destroy_memory_region_works(kvm_context);
+#endif
return 0;
}
@@ -793,6 +797,7 @@ void kvm_qemu_destroy(void)
kvm_finalize(kvm_context);
}
+#ifdef TARGET_I386
static int must_use_aliases_source(target_phys_addr_t addr)
{
if (destroy_region_works)
@@ -849,6 +854,7 @@ static void drop_mapping(target_phys_add
if (p)
*p = mappings[--nr_mappings];
}
+#endif
void kvm_cpu_register_physical_memory(target_phys_addr_t start_addr,
unsigned long size,
@@ -856,17 +862,21 @@ void kvm_cpu_register_physical_memory(ta
{
int r = 0;
unsigned long area_flags = phys_offset & ~TARGET_PAGE_MASK;
+#ifdef TARGET_I386
struct mapping *p;
+#endif
phys_offset &= ~IO_MEM_ROM;
if (area_flags == IO_MEM_UNASSIGNED) {
+#ifdef TARGET_I386
if (must_use_aliases_source(start_addr)) {
kvm_destroy_memory_alias(kvm_context, start_addr);
return;
}
if (must_use_aliases_target(start_addr))
return;
+#endif
kvm_unregister_memory_area(kvm_context, start_addr, size);
return;
}
@@ -878,6 +888,7 @@ void kvm_cpu_register_physical_memory(ta
if (area_flags >= TLB_MMIO)
return;
+#ifdef TARGET_I386
if (must_use_aliases_source(start_addr)) {
p = find_ram_mapping(phys_offset);
if (p) {
@@ -886,6 +897,7 @@ void kvm_cpu_register_physical_memory(ta
}
return;
}
+#endif
r = kvm_register_phys_mem(kvm_context, start_addr,
phys_ram_base + phys_offset,
@@ -895,11 +907,13 @@ void kvm_cpu_register_physical_memory(ta
exit(1);
}
+#ifdef TARGET_I386
drop_mapping(start_addr);
p = &mappings[nr_mappings++];
p->phys = start_addr;
p->ram = phys_offset;
p->len = size;
+#endif
return;
}
@@ -1068,8 +1082,10 @@ void kvm_qemu_log_memory(target_phys_add
if (log)
kvm_dirty_pages_log_enable_slot(kvm_context, start, size);
else {
+#ifdef TARGET_I386
if (must_use_aliases_target(start))
return;
+#endif
kvm_dirty_pages_log_disable_slot(kvm_context, start, size);
}
}
@@ -1157,8 +1173,10 @@ void kvm_physical_sync_dirty_bitmap(targ
{
void *buf;
+#ifdef TARGET_I386
if (must_use_aliases_source(start_addr))
return;
+#endif
buf = qemu_malloc((end_addr - start_addr) / 8 + 2);
kvm_get_dirty_pages_range(kvm_context, start_addr, end_addr - start_addr,
@@ -1168,21 +1186,21 @@ void kvm_physical_sync_dirty_bitmap(targ
int kvm_log_start(target_phys_addr_t phys_addr, target_phys_addr_t len)
{
-#ifndef TARGET_IA64
+#ifdef TARGET_I386
if (must_use_aliases_source(phys_addr))
return 0;
+#endif
kvm_qemu_log_memory(phys_addr, len, 1);
-#endif
return 0;
}
int kvm_log_stop(target_phys_addr_t phys_addr, target_phys_addr_t len)
{
-#ifndef TARGET_IA64
+#ifdef TARGET_I386
if (must_use_aliases_source(phys_addr))
return 0;
+#endif
kvm_qemu_log_memory(phys_addr, len, 0);
-#endif
return 0;
}
next prev parent reply other threads:[~2008-12-17 13:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081209161057.DC28A25006D@cleopatra.tlv.redhat.com>
2008-12-10 14:08 ` [PATCH] kvm: work around inability of older kvm modules to destroy memory regions Christian Ehrhardt
2008-12-17 12:26 ` Avi Kivity
2008-12-17 13:09 ` Christian Ehrhardt [this message]
2008-12-17 13:19 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4948FA08.8010505@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=avi@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cotte@de.ibm.com \
--cc=hollisb@us.ibm.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.