qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: HATAYAMA Daisuke
Subject: Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping
Date: Fri, 09 Mar 2012 09:40:17 +0900 ( )

From: Wen Congyang <address@hidden>
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 <address@hidden>
>> 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 <address@hidden>
>>> ---
>>>  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]