kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
 }


  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).