Re: [PATCH 04/04] qemu-kvm: other archs should maintain memory mapping also.

Avi Kivity <avi@xxxxxxxxxx> · Tue, 28 Apr 2009 12:39:30 +0300

Zhang, Xiantao wrote:

From d184d9b0a91ca674961000ed3d35b7fc25d29e03 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
Date: Tue, 28 Apr 2009 16:59:36 +0800
Subject: [PATCH] qemu-kvm: other archs should maintain memory mapping also.

 

Currently, use TARGET_I386 to comment out the mapping machanism

for other archs, but mapping machanism should be useful for other archs
to maintain guest's memory mapping.

 

  


Hollis, does this work for you?


If now, you can add a new define KVM_WANT_MAPPING or something, and 

define it for I386 and IA64.



Signed-off-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
---
 qemu-kvm.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/qemu-kvm.c b/qemu-kvm.c

index 68a9218..4f71192 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -846,6 +846,7 @@ static int must_use_aliases_target(target_phys_addr_t addr)
         return true;
     return false;
 }
+#endif

 

 static struct mapping {

     target_phys_addr_t phys;
@@ -885,7 +886,6 @@ static void drop_mapping(target_phys_addr_t start_addr)
     if (p)
         *p = mappings[--nr_mappings];
 }
-#endif

 

 void kvm_cpu_register_physical_memory(target_phys_addr_t start_addr,

                                       unsigned long size,
@@ -893,9 +893,7 @@ void kvm_cpu_register_physical_memory(target_phys_addr_t start_addr,
 {
     int r = 0;
     unsigned long area_flags;
-#ifdef TARGET_I386
     struct mapping *p;
-#endif

 

     if (start_addr + size > phys_ram_size) {

         phys_ram_size = start_addr + size;
@@ -955,13 +953,11 @@ void kvm_cpu_register_physical_memory(target_phys_addr_t start_addr,
         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;

 }

  



--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
