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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).