Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping

[Wen Congyang <wency@cn.fujitsu.com>]

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