Patchwork [RFC,05/16,v6] Add API to get memory mapping

login
register
mail settings
Submitter Wen Congyang
Date Feb. 9, 2012, 3:22 a.m.
Message ID <4F333C08.7070008@cn.fujitsu.com>
Download mbox | patch
Permalink /patch/140295/
State New
Headers show

Comments

Wen Congyang - Feb. 9, 2012, 3:22 a.m.
Add API to get all virtual address and physical address mapping.
If there is no virtual address for some physical address, the virtual
address is 0.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory_mapping.h |    1 +
 2 files changed, 66 insertions(+), 0 deletions(-)
Jan Kiszka - Feb. 14, 2012, 5:21 p.m.
On 2012-02-09 04:22, Wen Congyang wrote:
> Add API to get all virtual address and physical address mapping.
> If there is no virtual address for some physical address, the virtual
> address is 0.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  memory_mapping.h |    1 +
>  2 files changed, 66 insertions(+), 0 deletions(-)
> 
> diff --git a/memory_mapping.c b/memory_mapping.c
> index d83b7d7..fc0ddee 100644
> --- a/memory_mapping.c
> +++ b/memory_mapping.c
> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>  
>      list->num = 0;
>  }
> +
> +void get_memory_mapping(MemoryMappingList *list)
> +{
> +    CPUState *env;
> +    MemoryMapping *memory_mapping;
> +    RAMBlock *block;
> +    ram_addr_t offset, length;
> +
> +    last_mapping = NULL;
> +
> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
> +        cpu_get_memory_mapping(list, env);

Hmm, is the CPU number recorded along with the mappings? I mean, how
could crash tell them apart afterward if they are contradictory? This
way, they are just thrown in the same bucket, correct?

Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
could we already record that information for later use? Or would it
break compatibility with current versions?

> +    }
> +
> +    /* some memory may be not mapped, add them into memory mapping's list */
> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
> +        offset = block->offset;
> +        length = block->length;
> +
> +        QTAILQ_FOREACH(memory_mapping, &list->head, next) {
> +            if (memory_mapping->phys_addr >= (offset + length)) {
> +                /*
> +                 * memory_mapping's list does not conatin the region
> +                 * [offset, offset+length)
> +                 */
> +                create_new_memory_mapping(list, offset, 0, length);
> +                length = 0;
> +                break;
> +            }
> +
> +            if ((memory_mapping->phys_addr + memory_mapping->length) <=
> +                offset) {
> +                continue;
> +            }
> +
> +            if (memory_mapping->phys_addr > offset) {
> +                /*
> +                 * memory_mapping's list does not conatin the region
> +                 * [offset, memory_mapping->phys_addr)
> +                 */
> +                create_new_memory_mapping(list, offset, 0,
> +                                          memory_mapping->phys_addr - offset);
> +            }
> +
> +            if ((offset + length) <=
> +                (memory_mapping->phys_addr + memory_mapping->length)) {
> +                length = 0;
> +                break;
> +            }
> +            length -= memory_mapping->phys_addr + memory_mapping->length -
> +                      offset;
> +            offset = memory_mapping->phys_addr + memory_mapping->length;
> +        }
> +
> +        if (length > 0) {
> +            /*
> +             * memory_mapping's list does not conatin the region
> +             * [offset, memory_mapping->phys_addr)
> +             */
> +            create_new_memory_mapping(list, offset, 0, length);
> +        }
> +    }
> +
> +    return;

Please avoid redundant returns.

> +}
> diff --git a/memory_mapping.h b/memory_mapping.h
> index a4b1532..679f9ef 100644
> --- a/memory_mapping.h
> +++ b/memory_mapping.h
> @@ -34,5 +34,6 @@ void add_to_memory_mapping(MemoryMappingList *list,
>                             ram_addr_t length);
>  
>  void free_memory_mapping_list(MemoryMappingList *list);
> +void get_memory_mapping(MemoryMappingList *list);
>  
>  #endif

Maybe [qemu_]get_guest_memory_mapping. Just get_memory_mapping sounds a
bit to generic to me. Could be any mapping.

Jan
Wen Congyang - Feb. 15, 2012, 4:07 a.m.
At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
> On 2012-02-09 04:22, Wen Congyang wrote:
>> Add API to get all virtual address and physical address mapping.
>> If there is no virtual address for some physical address, the virtual
>> address is 0.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  memory_mapping.h |    1 +
>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>
>> diff --git a/memory_mapping.c b/memory_mapping.c
>> index d83b7d7..fc0ddee 100644
>> --- a/memory_mapping.c
>> +++ b/memory_mapping.c
>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>  
>>      list->num = 0;
>>  }
>> +
>> +void get_memory_mapping(MemoryMappingList *list)
>> +{
>> +    CPUState *env;
>> +    MemoryMapping *memory_mapping;
>> +    RAMBlock *block;
>> +    ram_addr_t offset, length;
>> +
>> +    last_mapping = NULL;
>> +
>> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
>> +        cpu_get_memory_mapping(list, env);
> 
> Hmm, is the CPU number recorded along with the mappings? I mean, how
> could crash tell them apart afterward if they are contradictory? This
> way, they are just thrown in the same bucket, correct?
> 
> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
> could we already record that information for later use? Or would it
> break compatibility with current versions?

crash does not need this information. It only needs the physical address
stored in PT_LOAD.

gdb needs the virtual address and physical address stored in PT_LOAD.

If the address is in the kernel space, the virtual address and physical
address mapping should be the same. I collect the mapping information
from all vcpus, because the OS may enter the second kernel. In this case,
IIRC(according to my test result, but I don't remeber clearly), gdb's bt
can output the backtrace in the first kernel if the OS does not use the
first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
the second kernel.

> 
>> +    }
>> +
>> +    /* some memory may be not mapped, add them into memory mapping's list */
>> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
>> +        offset = block->offset;
>> +        length = block->length;
>> +
>> +        QTAILQ_FOREACH(memory_mapping, &list->head, next) {
>> +            if (memory_mapping->phys_addr >= (offset + length)) {
>> +                /*
>> +                 * memory_mapping's list does not conatin the region
>> +                 * [offset, offset+length)
>> +                 */
>> +                create_new_memory_mapping(list, offset, 0, length);
>> +                length = 0;
>> +                break;
>> +            }
>> +
>> +            if ((memory_mapping->phys_addr + memory_mapping->length) <=
>> +                offset) {
>> +                continue;
>> +            }
>> +
>> +            if (memory_mapping->phys_addr > offset) {
>> +                /*
>> +                 * memory_mapping's list does not conatin the region
>> +                 * [offset, memory_mapping->phys_addr)
>> +                 */
>> +                create_new_memory_mapping(list, offset, 0,
>> +                                          memory_mapping->phys_addr - offset);
>> +            }
>> +
>> +            if ((offset + length) <=
>> +                (memory_mapping->phys_addr + memory_mapping->length)) {
>> +                length = 0;
>> +                break;
>> +            }
>> +            length -= memory_mapping->phys_addr + memory_mapping->length -
>> +                      offset;
>> +            offset = memory_mapping->phys_addr + memory_mapping->length;
>> +        }
>> +
>> +        if (length > 0) {
>> +            /*
>> +             * memory_mapping's list does not conatin the region
>> +             * [offset, memory_mapping->phys_addr)
>> +             */
>> +            create_new_memory_mapping(list, offset, 0, length);
>> +        }
>> +    }
>> +
>> +    return;
> 
> Please avoid redundant returns.

OK

> 
>> +}
>> diff --git a/memory_mapping.h b/memory_mapping.h
>> index a4b1532..679f9ef 100644
>> --- a/memory_mapping.h
>> +++ b/memory_mapping.h
>> @@ -34,5 +34,6 @@ void add_to_memory_mapping(MemoryMappingList *list,
>>                             ram_addr_t length);
>>  
>>  void free_memory_mapping_list(MemoryMappingList *list);
>> +void get_memory_mapping(MemoryMappingList *list);
>>  
>>  #endif
> 
> Maybe [qemu_]get_guest_memory_mapping. Just get_memory_mapping sounds a
> bit to generic to me. Could be any mapping.

OK, I will change the API's name

Thanks
Wen Congyang

> 
> Jan
>
Jan Kiszka - Feb. 15, 2012, 9:17 a.m.
On 2012-02-15 05:07, Wen Congyang wrote:
> At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
>> On 2012-02-09 04:22, Wen Congyang wrote:
>>> Add API to get all virtual address and physical address mapping.
>>> If there is no virtual address for some physical address, the virtual
>>> address is 0.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>> ---
>>>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  memory_mapping.h |    1 +
>>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>> index d83b7d7..fc0ddee 100644
>>> --- a/memory_mapping.c
>>> +++ b/memory_mapping.c
>>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>>  
>>>      list->num = 0;
>>>  }
>>> +
>>> +void get_memory_mapping(MemoryMappingList *list)
>>> +{
>>> +    CPUState *env;
>>> +    MemoryMapping *memory_mapping;
>>> +    RAMBlock *block;
>>> +    ram_addr_t offset, length;
>>> +
>>> +    last_mapping = NULL;
>>> +
>>> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>> +        cpu_get_memory_mapping(list, env);
>>
>> Hmm, is the CPU number recorded along with the mappings? I mean, how
>> could crash tell them apart afterward if they are contradictory? This
>> way, they are just thrown in the same bucket, correct?
>>
>> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
>> could we already record that information for later use? Or would it
>> break compatibility with current versions?
> 
> crash does not need this information. It only needs the physical address
> stored in PT_LOAD.

So crash does not support viewing memory through the eyes of different
CPUs? OK.

> 
> gdb needs the virtual address and physical address stored in PT_LOAD.
> 
> If the address is in the kernel space, the virtual address and physical
> address mapping should be the same. I collect the mapping information
> from all vcpus, because the OS may enter the second kernel. In this case,
> IIRC(according to my test result, but I don't remeber clearly), gdb's bt
> can output the backtrace in the first kernel if the OS does not use the
> first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
> the second kernel.

gdb could only make proper use of the additional mappings if they are
not contradictory (which can easily happen with user space processes) or
the cpu context is additionally provided so that views can be switched
via the "thread N" command. So far, QEMU's gdbstub does this for gdb
when it requests some memory over the remote connection. I bet gdb
requires some extension to exploit such information offline from a core
file, but I'm also sure that this will come as the importance of gdb for
system level debugging will rise.

Therefore my question: is there room to encode the mapping relation to a
CPU/thread context?

Jan
Wen Congyang - Feb. 15, 2012, 9:41 a.m.
At 02/15/2012 05:17 PM, Jan Kiszka Wrote:
> On 2012-02-15 05:07, Wen Congyang wrote:
>> At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
>>> On 2012-02-09 04:22, Wen Congyang wrote:
>>>> Add API to get all virtual address and physical address mapping.
>>>> If there is no virtual address for some physical address, the virtual
>>>> address is 0.
>>>>
>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>> ---
>>>>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  memory_mapping.h |    1 +
>>>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>>> index d83b7d7..fc0ddee 100644
>>>> --- a/memory_mapping.c
>>>> +++ b/memory_mapping.c
>>>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>>>  
>>>>      list->num = 0;
>>>>  }
>>>> +
>>>> +void get_memory_mapping(MemoryMappingList *list)
>>>> +{
>>>> +    CPUState *env;
>>>> +    MemoryMapping *memory_mapping;
>>>> +    RAMBlock *block;
>>>> +    ram_addr_t offset, length;
>>>> +
>>>> +    last_mapping = NULL;
>>>> +
>>>> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>> +        cpu_get_memory_mapping(list, env);
>>>
>>> Hmm, is the CPU number recorded along with the mappings? I mean, how
>>> could crash tell them apart afterward if they are contradictory? This
>>> way, they are just thrown in the same bucket, correct?
>>>
>>> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
>>> could we already record that information for later use? Or would it
>>> break compatibility with current versions?
>>
>> crash does not need this information. It only needs the physical address
>> stored in PT_LOAD.
> 
> So crash does not support viewing memory through the eyes of different
> CPUs? OK.
> 
>>
>> gdb needs the virtual address and physical address stored in PT_LOAD.
>>
>> If the address is in the kernel space, the virtual address and physical
>> address mapping should be the same. I collect the mapping information
>> from all vcpus, because the OS may enter the second kernel. In this case,
>> IIRC(according to my test result, but I don't remeber clearly), gdb's bt
>> can output the backtrace in the first kernel if the OS does not use the
>> first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
>> the second kernel.
> 
> gdb could only make proper use of the additional mappings if they are
> not contradictory (which can easily happen with user space processes) or
> the cpu context is additionally provided so that views can be switched
> via the "thread N" command. So far, QEMU's gdbstub does this for gdb
> when it requests some memory over the remote connection. I bet gdb
> requires some extension to exploit such information offline from a core
> file, but I'm also sure that this will come as the importance of gdb for
> system level debugging will rise.
> 
> Therefore my question: is there room to encode the mapping relation to a
> CPU/thread context?

I donot know. But I think the answer is no, because there is no filed
in the struct Elf32_Phdr/Elf64_Phdr to store the CPU/thread id.

Thanks
Wen Congyang

> 
> Jan
>
HATAYAMA Daisuke - Feb. 15, 2012, 9:47 a.m.
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 05/16 v6] Add API to get memory mapping
Date: Wed, 15 Feb 2012 17:41:15 +0800

> At 02/15/2012 05:17 PM, Jan Kiszka Wrote:
>> On 2012-02-15 05:07, Wen Congyang wrote:
>>> At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
>>>> On 2012-02-09 04:22, Wen Congyang wrote:
>>>>> Add API to get all virtual address and physical address mapping.
>>>>> If there is no virtual address for some physical address, the virtual
>>>>> address is 0.
>>>>>
>>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>>> ---
>>>>>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  memory_mapping.h |    1 +
>>>>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>>>> index d83b7d7..fc0ddee 100644
>>>>> --- a/memory_mapping.c
>>>>> +++ b/memory_mapping.c
>>>>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>>>>  
>>>>>      list->num = 0;
>>>>>  }
>>>>> +
>>>>> +void get_memory_mapping(MemoryMappingList *list)
>>>>> +{
>>>>> +    CPUState *env;
>>>>> +    MemoryMapping *memory_mapping;
>>>>> +    RAMBlock *block;
>>>>> +    ram_addr_t offset, length;
>>>>> +
>>>>> +    last_mapping = NULL;
>>>>> +
>>>>> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>>> +        cpu_get_memory_mapping(list, env);
>>>>
>>>> Hmm, is the CPU number recorded along with the mappings? I mean, how
>>>> could crash tell them apart afterward if they are contradictory? This
>>>> way, they are just thrown in the same bucket, correct?
>>>>
>>>> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
>>>> could we already record that information for later use? Or would it
>>>> break compatibility with current versions?
>>>
>>> crash does not need this information. It only needs the physical address
>>> stored in PT_LOAD.
>> 
>> So crash does not support viewing memory through the eyes of different
>> CPUs? OK.
>> 
>>>
>>> gdb needs the virtual address and physical address stored in PT_LOAD.
>>>
>>> If the address is in the kernel space, the virtual address and physical
>>> address mapping should be the same. I collect the mapping information
>>> from all vcpus, because the OS may enter the second kernel. In this case,
>>> IIRC(according to my test result, but I don't remeber clearly), gdb's bt
>>> can output the backtrace in the first kernel if the OS does not use the
>>> first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
>>> the second kernel.
>> 
>> gdb could only make proper use of the additional mappings if they are
>> not contradictory (which can easily happen with user space processes) or
>> the cpu context is additionally provided so that views can be switched
>> via the "thread N" command. So far, QEMU's gdbstub does this for gdb
>> when it requests some memory over the remote connection. I bet gdb
>> requires some extension to exploit such information offline from a core
>> file, but I'm also sure that this will come as the importance of gdb for
>> system level debugging will rise.
>> 
>> Therefore my question: is there room to encode the mapping relation to a
>> CPU/thread context?
> 
> I donot know. But I think the answer is no, because there is no filed
> in the struct Elf32_Phdr/Elf64_Phdr to store the CPU/thread id.
> 

See NT_PRSTATUS note, from which gdb knows what CPUs is related to
what thread.

For vmcore generated by kdump, NT_PRSTATUS notes is contained in the
order corresponding to online cpus.

If crash reads the vmcore generated by this command just as by kdump
and not considering this, crash might be understanding each CPU
information wrongly because qemu dump generated all possible CPUs.

Thanks.
HATAYAMA, Daisuke

> Thanks
> Wen Congyang
> 
>> 
>> Jan
>> 
> 
>
Jan Kiszka - Feb. 15, 2012, 10:19 a.m.
On 2012-02-15 10:47, HATAYAMA Daisuke wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [RFC][PATCH 05/16 v6] Add API to get memory mapping
> Date: Wed, 15 Feb 2012 17:41:15 +0800
> 
>> At 02/15/2012 05:17 PM, Jan Kiszka Wrote:
>>> On 2012-02-15 05:07, Wen Congyang wrote:
>>>> At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
>>>>> On 2012-02-09 04:22, Wen Congyang wrote:
>>>>>> Add API to get all virtual address and physical address mapping.
>>>>>> If there is no virtual address for some physical address, the virtual
>>>>>> address is 0.
>>>>>>
>>>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>>>> ---
>>>>>>  memory_mapping.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  memory_mapping.h |    1 +
>>>>>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>>>>> index d83b7d7..fc0ddee 100644
>>>>>> --- a/memory_mapping.c
>>>>>> +++ b/memory_mapping.c
>>>>>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>>>>>  
>>>>>>      list->num = 0;
>>>>>>  }
>>>>>> +
>>>>>> +void get_memory_mapping(MemoryMappingList *list)
>>>>>> +{
>>>>>> +    CPUState *env;
>>>>>> +    MemoryMapping *memory_mapping;
>>>>>> +    RAMBlock *block;
>>>>>> +    ram_addr_t offset, length;
>>>>>> +
>>>>>> +    last_mapping = NULL;
>>>>>> +
>>>>>> +    for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>>>> +        cpu_get_memory_mapping(list, env);
>>>>>
>>>>> Hmm, is the CPU number recorded along with the mappings? I mean, how
>>>>> could crash tell them apart afterward if they are contradictory? This
>>>>> way, they are just thrown in the same bucket, correct?
>>>>>
>>>>> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
>>>>> could we already record that information for later use? Or would it
>>>>> break compatibility with current versions?
>>>>
>>>> crash does not need this information. It only needs the physical address
>>>> stored in PT_LOAD.
>>>
>>> So crash does not support viewing memory through the eyes of different
>>> CPUs? OK.
>>>
>>>>
>>>> gdb needs the virtual address and physical address stored in PT_LOAD.
>>>>
>>>> If the address is in the kernel space, the virtual address and physical
>>>> address mapping should be the same. I collect the mapping information
>>>> from all vcpus, because the OS may enter the second kernel. In this case,
>>>> IIRC(according to my test result, but I don't remeber clearly), gdb's bt
>>>> can output the backtrace in the first kernel if the OS does not use the
>>>> first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
>>>> the second kernel.
>>>
>>> gdb could only make proper use of the additional mappings if they are
>>> not contradictory (which can easily happen with user space processes) or
>>> the cpu context is additionally provided so that views can be switched
>>> via the "thread N" command. So far, QEMU's gdbstub does this for gdb
>>> when it requests some memory over the remote connection. I bet gdb
>>> requires some extension to exploit such information offline from a core
>>> file, but I'm also sure that this will come as the importance of gdb for
>>> system level debugging will rise.
>>>
>>> Therefore my question: is there room to encode the mapping relation to a
>>> CPU/thread context?
>>
>> I donot know. But I think the answer is no, because there is no filed
>> in the struct Elf32_Phdr/Elf64_Phdr to store the CPU/thread id.
>>
> 
> See NT_PRSTATUS note, from which gdb knows what CPUs is related to
> what thread.
> 
> For vmcore generated by kdump, NT_PRSTATUS notes is contained in the
> order corresponding to online cpus.
> 
> If crash reads the vmcore generated by this command just as by kdump
> and not considering this, crash might be understanding each CPU
> information wrongly because qemu dump generated all possible CPUs.

If that note makes most sense to encode the mapping context, let's use
it and fix crash to be prepared for it.

Jan

Patch

diff --git a/memory_mapping.c b/memory_mapping.c
index d83b7d7..fc0ddee 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -128,3 +128,68 @@  void free_memory_mapping_list(MemoryMappingList *list)
 
     list->num = 0;
 }
+
+void get_memory_mapping(MemoryMappingList *list)
+{
+    CPUState *env;
+    MemoryMapping *memory_mapping;
+    RAMBlock *block;
+    ram_addr_t offset, length;
+
+    last_mapping = NULL;
+
+    for (env = first_cpu; env != NULL; env = env->next_cpu) {
+        cpu_get_memory_mapping(list, env);
+    }
+
+    /* some memory may be not mapped, add them into memory mapping's list */
+    QLIST_FOREACH(block, &ram_list.blocks, next) {
+        offset = block->offset;
+        length = block->length;
+
+        QTAILQ_FOREACH(memory_mapping, &list->head, next) {
+            if (memory_mapping->phys_addr >= (offset + length)) {
+                /*
+                 * memory_mapping's list does not conatin the region
+                 * [offset, offset+length)
+                 */
+                create_new_memory_mapping(list, offset, 0, length);
+                length = 0;
+                break;
+            }
+
+            if ((memory_mapping->phys_addr + memory_mapping->length) <=
+                offset) {
+                continue;
+            }
+
+            if (memory_mapping->phys_addr > offset) {
+                /*
+                 * memory_mapping's list does not conatin the region
+                 * [offset, memory_mapping->phys_addr)
+                 */
+                create_new_memory_mapping(list, offset, 0,
+                                          memory_mapping->phys_addr - offset);
+            }
+
+            if ((offset + length) <=
+                (memory_mapping->phys_addr + memory_mapping->length)) {
+                length = 0;
+                break;
+            }
+            length -= memory_mapping->phys_addr + memory_mapping->length -
+                      offset;
+            offset = memory_mapping->phys_addr + memory_mapping->length;
+        }
+
+        if (length > 0) {
+            /*
+             * memory_mapping's list does not conatin the region
+             * [offset, memory_mapping->phys_addr)
+             */
+            create_new_memory_mapping(list, offset, 0, length);
+        }
+    }
+
+    return;
+}
diff --git a/memory_mapping.h b/memory_mapping.h
index a4b1532..679f9ef 100644
--- a/memory_mapping.h
+++ b/memory_mapping.h
@@ -34,5 +34,6 @@  void add_to_memory_mapping(MemoryMappingList *list,
                            ram_addr_t length);
 
 void free_memory_mapping_list(MemoryMappingList *list);
+void get_memory_mapping(MemoryMappingList *list);
 
 #endif