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 <we...@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
>
