From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbKC-0002Ex-AN for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:39:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxbK6-0000Tk-AE for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:38:56 -0500 Received: from [222.73.24.84] (port=55688 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbK5-0000Ox-0m for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:38:50 -0500 Message-ID: <4F3B7DBB.6060807@cn.fujitsu.com> Date: Wed, 15 Feb 2012 17:41:15 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F333AAA.1070601@cn.fujitsu.com> <4F333C08.7070008@cn.fujitsu.com> <4F3A9803.2090608@siemens.com> <4F3B2F87.9050806@cn.fujitsu.com> <4F3B7846.4050207@siemens.com> In-Reply-To: <4F3B7846.4050207@siemens.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 05/16 v6] Add API to get memory mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Eric Blake , HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino 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 >>>> --- >>>> 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 >