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

[Wen Congyang]

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 <address@hidden>
>>>> ---
>>>>  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
>