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

[Avi Kivity <avi@redhat.com>]

Zhang, Xiantao wrote:
> From d184d9b0a91ca674961000ed3d35b7fc25d29e03 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <xiantao.zhang@intel.com>
> 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@intel.com>
> ---
>  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.