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

login
register
mail settings
Submitter Wen Congyang
Date March 2, 2012, 10:18 a.m.
Message ID <4F509E6F.9060801@cn.fujitsu.com>
Download mbox | patch
Permalink /patch/144195/
State New
Headers show

Comments

Wen Congyang - March 2, 2012, 10:18 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 |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 memory_mapping.h |    8 +++++
 2 files changed, 96 insertions(+), 0 deletions(-)
HATAYAMA Daisuke - March 7, 2012, 3:27 p.m.
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 02 Mar 2012 18:18:23 +0800

> 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 |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  memory_mapping.h |    8 +++++
>  2 files changed, 96 insertions(+), 0 deletions(-)
> 
> diff --git a/memory_mapping.c b/memory_mapping.c
> index 718f271..f74c5d0 100644
> --- a/memory_mapping.c
> +++ b/memory_mapping.c
> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list)
>      list->last_mapping = NULL;
>      QTAILQ_INIT(&list->head);
>  }
> +
> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
> +{
> +    CPUState *env;
> +    MemoryMapping *memory_mapping;
> +    RAMBlock *block;
> +    ram_addr_t offset, length, m_length;
> +    target_phys_addr_t m_phys_addr;
> +    int ret;
> +    bool paging_mode;
> +
> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
> +    paging_mode = cpu_paging_enabled(first_cpu);
> +    if (paging_mode) {
> +        for (env = first_cpu; env != NULL; env = env->next_cpu) {
> +            ret = cpu_get_memory_mapping(list, env);
> +            if (ret < 0) {
> +                return -1;
> +            }
> +        }
> +    }
> +#else
> +    return -2;
> +#endif
> +
> +    /*
> +     * some memory may be not in the memory mapping's list:
> +     * 1. the guest doesn't use paging
> +     * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
> +     *    in paging table
> +     * add them into memory mapping's list
> +     */
> +    QLIST_FOREACH(block, &ram_list.blocks, next) {

How does the memory portion referenced by PT_LOAD program headers with
p_vaddr == 0 looks through gdb? If we cannot access such portions,
part not referenced by the page table CR3 has is unnecessary, isn't
it?

Thanks.
HATAYAMA, Daisuke
Wen Congyang - March 8, 2012, 8:52 a.m.
At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 02 Mar 2012 18:18:23 +0800
> 
>> 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 |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  memory_mapping.h |    8 +++++
>>  2 files changed, 96 insertions(+), 0 deletions(-)
>>
>> diff --git a/memory_mapping.c b/memory_mapping.c
>> index 718f271..f74c5d0 100644
>> --- a/memory_mapping.c
>> +++ b/memory_mapping.c
>> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list)
>>      list->last_mapping = NULL;
>>      QTAILQ_INIT(&list->head);
>>  }
>> +
>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
>> +{
>> +    CPUState *env;
>> +    MemoryMapping *memory_mapping;
>> +    RAMBlock *block;
>> +    ram_addr_t offset, length, m_length;
>> +    target_phys_addr_t m_phys_addr;
>> +    int ret;
>> +    bool paging_mode;
>> +
>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
>> +    paging_mode = cpu_paging_enabled(first_cpu);
>> +    if (paging_mode) {
>> +        for (env = first_cpu; env != NULL; env = env->next_cpu) {
>> +            ret = cpu_get_memory_mapping(list, env);
>> +            if (ret < 0) {
>> +                return -1;
>> +            }
>> +        }
>> +    }
>> +#else
>> +    return -2;
>> +#endif
>> +
>> +    /*
>> +     * some memory may be not in the memory mapping's list:
>> +     * 1. the guest doesn't use paging
>> +     * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
>> +     *    in paging table
>> +     * add them into memory mapping's list
>> +     */
>> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
> 
> How does the memory portion referenced by PT_LOAD program headers with
> p_vaddr == 0 looks through gdb? If we cannot access such portions,
> part not referenced by the page table CR3 has is unnecessary, isn't
> it?

The part is unnecessary if you use gdb. But it is necessary if you use crash.

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
>
HATAYAMA Daisuke - March 9, 2012, 12:40 a.m.
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Thu, 08 Mar 2012 16:52:29 +0800

> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>> 
>>> 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 |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  memory_mapping.h |    8 +++++
>>>  2 files changed, 96 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>> index 718f271..f74c5d0 100644
>>> --- a/memory_mapping.c
>>> +++ b/memory_mapping.c
>>> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list)
>>>      list->last_mapping = NULL;
>>>      QTAILQ_INIT(&list->head);
>>>  }
>>> +
>>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
>>> +{
>>> +    CPUState *env;
>>> +    MemoryMapping *memory_mapping;
>>> +    RAMBlock *block;
>>> +    ram_addr_t offset, length, m_length;
>>> +    target_phys_addr_t m_phys_addr;
>>> +    int ret;
>>> +    bool paging_mode;
>>> +
>>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
>>> +    paging_mode = cpu_paging_enabled(first_cpu);
>>> +    if (paging_mode) {
>>> +        for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>> +            ret = cpu_get_memory_mapping(list, env);
>>> +            if (ret < 0) {
>>> +                return -1;
>>> +            }
>>> +        }
>>> +    }
>>> +#else
>>> +    return -2;
>>> +#endif
>>> +
>>> +    /*
>>> +     * some memory may be not in the memory mapping's list:
>>> +     * 1. the guest doesn't use paging
>>> +     * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
>>> +     *    in paging table
>>> +     * add them into memory mapping's list
>>> +     */
>>> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
>> 
>> How does the memory portion referenced by PT_LOAD program headers with
>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>> part not referenced by the page table CR3 has is unnecessary, isn't
>> it?
> 
> The part is unnecessary if you use gdb. But it is necessary if you use crash.
> 

crash users would not use paging option because even if without using
it, we can see all memory well, so the paging option is only for gdb
users.

It looks to me that the latter part only complicates the logic. If
instead, collecting virtual addresses only, way of handling PT_LOAD
entries become simpler, for example, they no longer need to be
physically contiguous in a single entry, and reviewing and maintaince
becomes easy.

Thanks.
HATAYAMA, Daisuke
Wen Congyang - March 9, 2012, 1:46 a.m.
At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Thu, 08 Mar 2012 16:52:29 +0800
> 
>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>
>>>> 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 |   88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  memory_mapping.h |    8 +++++
>>>>  2 files changed, 96 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>>> index 718f271..f74c5d0 100644
>>>> --- a/memory_mapping.c
>>>> +++ b/memory_mapping.c
>>>> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list)
>>>>      list->last_mapping = NULL;
>>>>      QTAILQ_INIT(&list->head);
>>>>  }
>>>> +
>>>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
>>>> +{
>>>> +    CPUState *env;
>>>> +    MemoryMapping *memory_mapping;
>>>> +    RAMBlock *block;
>>>> +    ram_addr_t offset, length, m_length;
>>>> +    target_phys_addr_t m_phys_addr;
>>>> +    int ret;
>>>> +    bool paging_mode;
>>>> +
>>>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
>>>> +    paging_mode = cpu_paging_enabled(first_cpu);
>>>> +    if (paging_mode) {
>>>> +        for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>> +            ret = cpu_get_memory_mapping(list, env);
>>>> +            if (ret < 0) {
>>>> +                return -1;
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +#else
>>>> +    return -2;
>>>> +#endif
>>>> +
>>>> +    /*
>>>> +     * some memory may be not in the memory mapping's list:
>>>> +     * 1. the guest doesn't use paging
>>>> +     * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
>>>> +     *    in paging table
>>>> +     * add them into memory mapping's list
>>>> +     */
>>>> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
>>>
>>> How does the memory portion referenced by PT_LOAD program headers with
>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>> it?
>>
>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>
> 
> crash users would not use paging option because even if without using
> it, we can see all memory well, so the paging option is only for gdb
> users.

Yes, the paging option is only for gdb users. The default value if off.

> 
> It looks to me that the latter part only complicates the logic. If
> instead, collecting virtual addresses only, way of handling PT_LOAD
> entries become simpler, for example, they no longer need to be
> physically contiguous in a single entry, and reviewing and maintaince
> becomes easy.

Sorry, I donot understand what do you want to say.

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
>
HATAYAMA Daisuke - March 9, 2012, 2:05 a.m.
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 09 Mar 2012 09:46:31 +0800

> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>> 
>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>
>>>>

>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>> it?
>>>
>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>
>> 
>> crash users would not use paging option because even if without using
>> it, we can see all memory well, so the paging option is only for gdb
>> users.
> 
> Yes, the paging option is only for gdb users. The default value if off.
> 
>> 
>> It looks to me that the latter part only complicates the logic. If
>> instead, collecting virtual addresses only, way of handling PT_LOAD
>> entries become simpler, for example, they no longer need to be
>> physically contiguous in a single entry, and reviewing and maintaince
>> becomes easy.
> 
> Sorry, I donot understand what do you want to say.
> 

The processing that adds part not referenced by page table to vmcore
is meaningless for gdb. crash doesn't require it. So, it only
complicates the current logic.

Thanks.
HATAYAMA, Daisuke
Wen Congyang - March 9, 2012, 2:26 a.m.
At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 09 Mar 2012 09:46:31 +0800
> 
>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>
>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>
>>>>>
> 
>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>> it?
>>>>
>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>
>>>
>>> crash users would not use paging option because even if without using
>>> it, we can see all memory well, so the paging option is only for gdb
>>> users.
>>
>> Yes, the paging option is only for gdb users. The default value if off.
>>
>>>
>>> It looks to me that the latter part only complicates the logic. If
>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>> entries become simpler, for example, they no longer need to be
>>> physically contiguous in a single entry, and reviewing and maintaince
>>> becomes easy.
>>
>> Sorry, I donot understand what do you want to say.
>>
> 
> The processing that adds part not referenced by page table to vmcore
> is meaningless for gdb. crash doesn't require it. So, it only
> complicates the current logic.

If the paging mode is on, we can also use crash to analyze the vmcore.
As the comment methioned, the memory used by the 1st kernel may be not
referenced by the page table, so we neet this logic.

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
>
HATAYAMA Daisuke - March 9, 2012, 2:53 a.m.
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 09 Mar 2012 10:26:56 +0800

> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>> 
>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>
>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>
>>>>>>
>> 
>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>> it?
>>>>>
>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>
>>>>
>>>> crash users would not use paging option because even if without using
>>>> it, we can see all memory well, so the paging option is only for gdb
>>>> users.
>>>
>>> Yes, the paging option is only for gdb users. The default value if off.
>>>
>>>>
>>>> It looks to me that the latter part only complicates the logic. If
>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>> entries become simpler, for example, they no longer need to be
>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>> becomes easy.
>>>
>>> Sorry, I donot understand what do you want to say.
>>>
>> 
>> The processing that adds part not referenced by page table to vmcore
>> is meaningless for gdb. crash doesn't require it. So, it only
>> complicates the current logic.
> 
> If the paging mode is on, we can also use crash to analyze the vmcore.
> As the comment methioned, the memory used by the 1st kernel may be not
> referenced by the page table, so we neet this logic.
> 

As I said several times, crash users don't use paging mode. Users of
the paging mode is gdb only just as you say. So, the paging path needs
to collect part referenced by page table only since the other part is
invisible to gdb.

Thanks.
HATAYAMA, Daisuke
Jan Kiszka - March 9, 2012, 9:41 a.m.
On 2012-03-09 03:53, HATAYAMA Daisuke wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 09 Mar 2012 10:26:56 +0800
> 
>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>>>
>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>>
>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>>
>>>>>>>
>>>
>>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>>> it?
>>>>>>
>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>>
>>>>>
>>>>> crash users would not use paging option because even if without using
>>>>> it, we can see all memory well, so the paging option is only for gdb
>>>>> users.
>>>>
>>>> Yes, the paging option is only for gdb users. The default value if off.
>>>>
>>>>>
>>>>> It looks to me that the latter part only complicates the logic. If
>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>>> entries become simpler, for example, they no longer need to be
>>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>>> becomes easy.
>>>>
>>>> Sorry, I donot understand what do you want to say.
>>>>
>>>
>>> The processing that adds part not referenced by page table to vmcore
>>> is meaningless for gdb. crash doesn't require it. So, it only
>>> complicates the current logic.
>>
>> If the paging mode is on, we can also use crash to analyze the vmcore.
>> As the comment methioned, the memory used by the 1st kernel may be not
>> referenced by the page table, so we neet this logic.
>>
> 
> As I said several times, crash users don't use paging mode. Users of
> the paging mode is gdb only just as you say. So, the paging path needs
> to collect part referenced by page table only since the other part is
> invisible to gdb.

If crash can work both with and without paging, it should be default
*on* to avoid writing cores that can later on only be analyzed with that
tool. Still not sure, though, if that changes the requirement on what
memory regions should be written in that mode.

Jan
Jan Kiszka - March 9, 2012, 9:43 a.m.
On 2012-03-09 03:53, HATAYAMA Daisuke wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 09 Mar 2012 10:26:56 +0800
> 
>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>>>
>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>>
>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>>
>>>>>>>
>>>
>>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>>> it?
>>>>>>
>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>>
>>>>>
>>>>> crash users would not use paging option because even if without using
>>>>> it, we can see all memory well, so the paging option is only for gdb
>>>>> users.
>>>>
>>>> Yes, the paging option is only for gdb users. The default value if off.
>>>>
>>>>>
>>>>> It looks to me that the latter part only complicates the logic. If
>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>>> entries become simpler, for example, they no longer need to be
>>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>>> becomes easy.
>>>>
>>>> Sorry, I donot understand what do you want to say.
>>>>
>>>
>>> The processing that adds part not referenced by page table to vmcore
>>> is meaningless for gdb. crash doesn't require it. So, it only
>>> complicates the current logic.
>>
>> If the paging mode is on, we can also use crash to analyze the vmcore.
>> As the comment methioned, the memory used by the 1st kernel may be not
>> referenced by the page table, so we neet this logic.
>>
> 
> As I said several times, crash users don't use paging mode. Users of
> the paging mode is gdb only just as you say. So, the paging path needs
> to collect part referenced by page table only since the other part is
> invisible to gdb.

If crash can work both with and without paging, it should be default
*on* to avoid writing cores that can later on only be analyzed with that
tool. Still not sure, though, if that changes the requirement on what
memory regions should be written in that mode.

Jan
Wen Congyang - March 9, 2012, 9:57 a.m.
At 03/09/2012 05:41 PM, Jan Kiszka Wrote:
> On 2012-03-09 03:53, HATAYAMA Daisuke wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>> Date: Fri, 09 Mar 2012 10:26:56 +0800
>>
>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>>>>
>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>>>
>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>>>> it?
>>>>>>>
>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>>>
>>>>>>
>>>>>> crash users would not use paging option because even if without using
>>>>>> it, we can see all memory well, so the paging option is only for gdb
>>>>>> users.
>>>>>
>>>>> Yes, the paging option is only for gdb users. The default value if off.
>>>>>
>>>>>>
>>>>>> It looks to me that the latter part only complicates the logic. If
>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>>>> entries become simpler, for example, they no longer need to be
>>>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>>>> becomes easy.
>>>>>
>>>>> Sorry, I donot understand what do you want to say.
>>>>>
>>>>
>>>> The processing that adds part not referenced by page table to vmcore
>>>> is meaningless for gdb. crash doesn't require it. So, it only
>>>> complicates the current logic.
>>>
>>> If the paging mode is on, we can also use crash to analyze the vmcore.
>>> As the comment methioned, the memory used by the 1st kernel may be not
>>> referenced by the page table, so we neet this logic.
>>>
>>
>> As I said several times, crash users don't use paging mode. Users of
>> the paging mode is gdb only just as you say. So, the paging path needs
>> to collect part referenced by page table only since the other part is
>> invisible to gdb.
> 
> If crash can work both with and without paging, it should be default
> *on* to avoid writing cores that can later on only be analyzed with that
> tool. Still not sure, though, if that changes the requirement on what
> memory regions should be written in that mode.

If this logic is not remvoed, crash can work both with and without paging.
But the default value is 'off' now, because the option is '-p'.

Thanks
Wen Congyang

> 
> Jan
>
Jan Kiszka - March 9, 2012, 10:05 a.m.
On 2012-03-09 10:57, Wen Congyang wrote:
> At 03/09/2012 05:41 PM, Jan Kiszka Wrote:
>> On 2012-03-09 03:53, HATAYAMA Daisuke wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>> Date: Fri, 09 Mar 2012 10:26:56 +0800
>>>
>>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>>>>>
>>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>>>>
>>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>>>>> it?
>>>>>>>>
>>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>>>>
>>>>>>>
>>>>>>> crash users would not use paging option because even if without using
>>>>>>> it, we can see all memory well, so the paging option is only for gdb
>>>>>>> users.
>>>>>>
>>>>>> Yes, the paging option is only for gdb users. The default value if off.
>>>>>>
>>>>>>>
>>>>>>> It looks to me that the latter part only complicates the logic. If
>>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>>>>> entries become simpler, for example, they no longer need to be
>>>>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>>>>> becomes easy.
>>>>>>
>>>>>> Sorry, I donot understand what do you want to say.
>>>>>>
>>>>>
>>>>> The processing that adds part not referenced by page table to vmcore
>>>>> is meaningless for gdb. crash doesn't require it. So, it only
>>>>> complicates the current logic.
>>>>
>>>> If the paging mode is on, we can also use crash to analyze the vmcore.
>>>> As the comment methioned, the memory used by the 1st kernel may be not
>>>> referenced by the page table, so we neet this logic.
>>>>
>>>
>>> As I said several times, crash users don't use paging mode. Users of
>>> the paging mode is gdb only just as you say. So, the paging path needs
>>> to collect part referenced by page table only since the other part is
>>> invisible to gdb.
>>
>> If crash can work both with and without paging, it should be default
>> *on* to avoid writing cores that can later on only be analyzed with that
>> tool. Still not sure, though, if that changes the requirement on what
>> memory regions should be written in that mode.
> 
> If this logic is not remvoed, crash can work both with and without paging.
> But the default value is 'off' now, because the option is '-p'.

And this would be unfortunate if you do not want to use crash for
analyzing (I'm working on gdb python scripts which will make gdb - one
day - at least as powerful as crash). If paging mode has the same
information that non-paging mode has, I would even suggest to drop it.

Jan
Jan Kiszka - March 9, 2012, 10:06 a.m.
On 2012-03-09 11:05, Jan Kiszka wrote:
>>> If crash can work both with and without paging, it should be default
>>> *on* to avoid writing cores that can later on only be analyzed with that
>>> tool. Still not sure, though, if that changes the requirement on what
>>> memory regions should be written in that mode.
>>
>> If this logic is not remvoed, crash can work both with and without paging.
>> But the default value is 'off' now, because the option is '-p'.
> 
> And this would be unfortunate if you do not want to use crash for
> analyzing (I'm working on gdb python scripts which will make gdb - one
> day - at least as powerful as crash). If paging mode has the same
> information that non-paging mode has, I would even suggest to drop it.

Err, with "it" = "non-paging mode".

Jan
HATAYAMA Daisuke - March 9, 2012, 12:53 p.m.
From: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 09 Mar 2012 11:06:30 +0100

> On 2012-03-09 11:05, Jan Kiszka wrote:
>>>> If crash can work both with and without paging, it should be default
>>>> *on* to avoid writing cores that can later on only be analyzed with that
>>>> tool. Still not sure, though, if that changes the requirement on what
>>>> memory regions should be written in that mode.
>>>
>>> If this logic is not remvoed, crash can work both with and without paging.
>>> But the default value is 'off' now, because the option is '-p'.
>> 
>> And this would be unfortunate if you do not want to use crash for
>> analyzing (I'm working on gdb python scripts which will make gdb - one
>> day - at least as powerful as crash). If paging mode has the same
>> information that non-paging mode has, I would even suggest to drop it.
> 
> Err, with "it" = "non-paging mode".
> 
> Jan

Paging at default is not good idea. Performing paging in qemu has risk.

  - Guest machine is not always in the state where paging mode is
    enabled. Also, CR3 doesn't always refer to page table.

  - If guest machine is in catastrophic state, its memory data could
    be corrupted. Then, we cannot trust such corrupted page table.

    # In this point, managing PT_LOAD program headers based on such
    # potencially corruppted data has risk.

The idea of yours that performing paging in debugger side is better
than doing in qemu.

Thanks.
HATAYAMA, Daisuke
Jan Kiszka - March 9, 2012, 1:24 p.m.
On 2012-03-09 13:53, HATAYAMA Daisuke wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 09 Mar 2012 11:06:30 +0100
> 
>> On 2012-03-09 11:05, Jan Kiszka wrote:
>>>>> If crash can work both with and without paging, it should be default
>>>>> *on* to avoid writing cores that can later on only be analyzed with that
>>>>> tool. Still not sure, though, if that changes the requirement on what
>>>>> memory regions should be written in that mode.
>>>>
>>>> If this logic is not remvoed, crash can work both with and without paging.
>>>> But the default value is 'off' now, because the option is '-p'.
>>>
>>> And this would be unfortunate if you do not want to use crash for
>>> analyzing (I'm working on gdb python scripts which will make gdb - one
>>> day - at least as powerful as crash). If paging mode has the same
>>> information that non-paging mode has, I would even suggest to drop it.
>>
>> Err, with "it" = "non-paging mode".
>>
>> Jan
> 
> Paging at default is not good idea. Performing paging in qemu has risk.
> 
>   - Guest machine is not always in the state where paging mode is
>     enabled. Also, CR3 doesn't always refer to page table.

That's detectable and means physical == linear address.

> 
>   - If guest machine is in catastrophic state, its memory data could
>     be corrupted. Then, we cannot trust such corrupted page table.

OK, here I agree.

> 
>     # In this point, managing PT_LOAD program headers based on such
>     # potencially corruppted data has risk.
> 
> The idea of yours that performing paging in debugger side is better
> than doing in qemu.

Another alternative is to add guest-awareness to the dump code. If we
detect (or get told) that the target is a Linux kernel, at least the
linear kernel mapping can be written reliably.

But also the fact that there can be as many different page tables as
active processors means that paging likely needs a second thought and
more awareness of the debugger.

Jan
Wen Congyang - March 12, 2012, 1:52 a.m.
At 03/09/2012 06:05 PM, Jan Kiszka Wrote:
> On 2012-03-09 10:57, Wen Congyang wrote:
>> At 03/09/2012 05:41 PM, Jan Kiszka Wrote:
>>> On 2012-03-09 03:53, HATAYAMA Daisuke wrote:
>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>> Date: Fri, 09 Mar 2012 10:26:56 +0800
>>>>
>>>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote:
>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800
>>>>>>
>>>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote:
>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800
>>>>>>>>
>>>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote:
>>>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>>>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with
>>>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions,
>>>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't
>>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash.
>>>>>>>>>
>>>>>>>>
>>>>>>>> crash users would not use paging option because even if without using
>>>>>>>> it, we can see all memory well, so the paging option is only for gdb
>>>>>>>> users.
>>>>>>>
>>>>>>> Yes, the paging option is only for gdb users. The default value if off.
>>>>>>>
>>>>>>>>
>>>>>>>> It looks to me that the latter part only complicates the logic. If
>>>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD
>>>>>>>> entries become simpler, for example, they no longer need to be
>>>>>>>> physically contiguous in a single entry, and reviewing and maintaince
>>>>>>>> becomes easy.
>>>>>>>
>>>>>>> Sorry, I donot understand what do you want to say.
>>>>>>>
>>>>>>
>>>>>> The processing that adds part not referenced by page table to vmcore
>>>>>> is meaningless for gdb. crash doesn't require it. So, it only
>>>>>> complicates the current logic.
>>>>>
>>>>> If the paging mode is on, we can also use crash to analyze the vmcore.
>>>>> As the comment methioned, the memory used by the 1st kernel may be not
>>>>> referenced by the page table, so we neet this logic.
>>>>>
>>>>
>>>> As I said several times, crash users don't use paging mode. Users of
>>>> the paging mode is gdb only just as you say. So, the paging path needs
>>>> to collect part referenced by page table only since the other part is
>>>> invisible to gdb.
>>>
>>> If crash can work both with and without paging, it should be default
>>> *on* to avoid writing cores that can later on only be analyzed with that
>>> tool. Still not sure, though, if that changes the requirement on what
>>> memory regions should be written in that mode.
>>
>> If this logic is not remvoed, crash can work both with and without paging.
>> But the default value is 'off' now, because the option is '-p'.
> 
> And this would be unfortunate if you do not want to use crash for
> analyzing (I'm working on gdb python scripts which will make gdb - one
> day - at least as powerful as crash). If paging mode has the same
> information that non-paging mode has, I would even suggest to drop it.

I donot have any knowledge about gdb python scripts. But is it OK to work
without virtual address in PT_LOAD?

Thanks
Wen Congyang

> 
> Jan
>
HATAYAMA Daisuke - March 12, 2012, 6:16 a.m.
From: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 09 Mar 2012 14:24:41 +0100

> On 2012-03-09 13:53, HATAYAMA Daisuke wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
>> Date: Fri, 09 Mar 2012 11:06:30 +0100
>> 
>>> On 2012-03-09 11:05, Jan Kiszka wrote:
>>>>>> If crash can work both with and without paging, it should be default
>>>>>> *on* to avoid writing cores that can later on only be analyzed with that
>>>>>> tool. Still not sure, though, if that changes the requirement on what
>>>>>> memory regions should be written in that mode.
>>>>>
>>>>> If this logic is not remvoed, crash can work both with and without paging.
>>>>> But the default value is 'off' now, because the option is '-p'.
>>>>
>>>> And this would be unfortunate if you do not want to use crash for
>>>> analyzing (I'm working on gdb python scripts which will make gdb - one
>>>> day - at least as powerful as crash). If paging mode has the same
>>>> information that non-paging mode has, I would even suggest to drop it.
>>>
>>> Err, with "it" = "non-paging mode".
>>>
>>> Jan
>> 
>> Paging at default is not good idea. Performing paging in qemu has risk.
>> 
>>   - Guest machine is not always in the state where paging mode is
>>     enabled. Also, CR3 doesn't always refer to page table.
> 
> That's detectable and means physical == linear address.
> 

CR0 itself is one of the guest's resources. There's still the issue
whether to trust CR0 or not.

The assumption behind my idea is the host is running in a good
condition but the quest in a bad condition. So we can use qemu dump,
which is the host's feature.

Only checking if CR3 refers to page table correctly is considerably
complicated. CR3 can have any physical address. There's no hint such
as magic number to check it's invalid. So, to check if CR3 correctly
points at page table, the only way is to check if we can see the data
through actually performing paging for some virtual address. The
virtual address would be better if it's more typical one, but it tends
to be guest specific, and I think it's not suitable for qemu due to OS
dependency.
# Of course, this story is done out of the assumption that the data
# could be corrupted.

>> 
>>   - If guest machine is in catastrophic state, its memory data could
>>     be corrupted. Then, we cannot trust such corrupted page table.
> 
> OK, here I agree.
> 
>> 
>>     # In this point, managing PT_LOAD program headers based on such
>>     # potencially corruppted data has risk.
>> 
>> The idea of yours that performing paging in debugger side is better
>> than doing in qemu.
> 
> Another alternative is to add guest-awareness to the dump code. If we
> detect (or get told) that the target is a Linux kernel, at least the
> linear kernel mapping can be written reliably.
> 
> But also the fact that there can be as many different page tables as
> active processors means that paging likely needs a second thought and
> more awareness of the debugger.

Also, it seems to me that the lacking feature of gdb used to dumpfile
compared with used to running guest is paging only. Paging is a
feature in architecture, which is unlikely to change in the
future. It's better in maintainability than introducing OS-level
dependency.

Thanks.
HATAYAMA, Daisuke
HATAYAMA Daisuke - March 12, 2012, 6:26 a.m.
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Subject: Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Mon, 12 Mar 2012 15:16:55 +0900 (   )

> 
> The assumption behind my idea is the host is running in a good
> condition but the quest in a bad condition. So we can use qemu dump,
> which is the host's feature.

There's also the situation that a guest is running in a good condition
and users can recognize that its data is obviously not corrupted. For
such situation, it's natural for qemu dump to have paging mode to some
amount.

Thanks.
HATAYAMA, Daisuke

Patch

diff --git a/memory_mapping.c b/memory_mapping.c
index 718f271..f74c5d0 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -164,3 +164,91 @@  void memory_mapping_list_init(MemoryMappingList *list)
     list->last_mapping = NULL;
     QTAILQ_INIT(&list->head);
 }
+
+int qemu_get_guest_memory_mapping(MemoryMappingList *list)
+{
+    CPUState *env;
+    MemoryMapping *memory_mapping;
+    RAMBlock *block;
+    ram_addr_t offset, length, m_length;
+    target_phys_addr_t m_phys_addr;
+    int ret;
+    bool paging_mode;
+
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+    paging_mode = cpu_paging_enabled(first_cpu);
+    if (paging_mode) {
+        for (env = first_cpu; env != NULL; env = env->next_cpu) {
+            ret = cpu_get_memory_mapping(list, env);
+            if (ret < 0) {
+                return -1;
+            }
+        }
+    }
+#else
+    return -2;
+#endif
+
+    /*
+     * some memory may be not in the memory mapping's list:
+     * 1. the guest doesn't use paging
+     * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not
+     *    in paging table
+     * add them into memory mapping's list
+     */
+    QLIST_FOREACH(block, &ram_list.blocks, next) {
+        offset = block->offset;
+        length = block->length;
+
+        if (!paging_mode) {
+            create_new_memory_mapping(list, offset, offset, length);
+            continue;
+        }
+
+        QTAILQ_FOREACH(memory_mapping, &list->head, next) {
+            m_phys_addr = memory_mapping->phys_addr;
+            m_length = memory_mapping->length;
+
+            if (offset + length <= m_phys_addr) {
+                /*
+                 * memory_mapping's list does not conatin the region
+                 * [offset, offset+length)
+                 */
+                create_new_memory_mapping(list, offset, 0, length);
+                length = 0;
+                break;
+            }
+
+            if (m_phys_addr + m_length <= offset) {
+                continue;
+            }
+
+            if (m_phys_addr > offset) {
+                /*
+                 * memory_mapping's list does not conatin the region
+                 * [offset, memory_mapping->phys_addr)
+                 */
+                create_new_memory_mapping(list, offset, 0,
+                                          m_phys_addr - offset);
+            }
+
+            if (offset + length <= m_phys_addr + m_length) {
+                length = 0;
+                break;
+            }
+
+            length -= m_phys_addr + m_length - offset;
+            offset = m_phys_addr + m_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 0;
+}
diff --git a/memory_mapping.h b/memory_mapping.h
index 836b047..ebd7cf6 100644
--- a/memory_mapping.h
+++ b/memory_mapping.h
@@ -44,4 +44,12 @@  void memory_mapping_list_free(MemoryMappingList *list);
 
 void memory_mapping_list_init(MemoryMappingList *list);
 
+/*
+ * Return value:
+ *    0: success
+ *   -1: failed
+ *   -2: unsupported
+ */
+int qemu_get_guest_memory_mapping(MemoryMappingList *list);
+
 #endif