From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxb0D-00084g-Re for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:18:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rxb06-0004GC-Jy for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:18:17 -0500 Received: from goliath.siemens.de ([192.35.17.28]:24538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxb06-0004Fz-3g for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:18:10 -0500 Message-ID: <4F3B7846.4050207@siemens.com> Date: Wed, 15 Feb 2012 10:17:58 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F333AAA.1070601@cn.fujitsu.com> <4F333C08.7070008@cn.fujitsu.com> <4F3A9803.2090608@siemens.com> <4F3B2F87.9050806@cn.fujitsu.com> In-Reply-To: <4F3B2F87.9050806@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wen Congyang Cc: Eric Blake , HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino 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? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux