From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5p8N-0003OC-D1 for qemu-devel@nongnu.org; Thu, 08 Mar 2012 21:00:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5p81-0003bn-00 for qemu-devel@nongnu.org; Thu, 08 Mar 2012 21:00:42 -0500 Received: from [222.73.24.84] (port=39788 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5p80-0003bJ-Kd for qemu-devel@nongnu.org; Thu, 08 Mar 2012 21:00:20 -0500 Message-ID: <4F5960F7.6040206@cn.fujitsu.com> Date: Fri, 09 Mar 2012 09:46:31 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F509E6F.9060801@cn.fujitsu.com> <20120308.002717.276769760.d.hatayama@jp.fujitsu.com> <4F58734D.5070804@cn.fujitsu.com> <20120309.094017.193680568.d.hatayama@jp.fujitsu.com> In-Reply-To: <20120309.094017.193680568.d.hatayama@jp.fujitsu.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HATAYAMA Daisuke Cc: jan.kiszka@siemens.com, anderson@redhat.com, qemu-devel@nongnu.org, eblake@redhat.com, lcapitulino@redhat.com At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: > From: Wen Congyang > 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 >>> 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 >>>> --- >>>> 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. Yes, the paging option is only for gdb users. The default value if off. > > 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. Sorry, I donot understand what do you want to say. Thanks Wen Congyang > > Thanks. > HATAYAMA, Daisuke > >