From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6uZM-00020V-K7 for qemu-devel@nongnu.org; Sun, 11 Mar 2012 22:01:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6uZK-0006q4-G0 for qemu-devel@nongnu.org; Sun, 11 Mar 2012 22:01:04 -0400 Received: from [222.73.24.84] (port=47674 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6uZK-0006po-4D for qemu-devel@nongnu.org; Sun, 11 Mar 2012 22:01:02 -0400 Message-ID: <4F5D56FB.2050307@cn.fujitsu.com> Date: Mon, 12 Mar 2012 09:52:59 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F5960F7.6040206@cn.fujitsu.com> <20120309.110533.71105037.d.hatayama@jp.fujitsu.com> <4F596A70.9050808@cn.fujitsu.com> <20120309.115325.104044385.d.hatayama@jp.fujitsu.com> <4F59D040.3060506@siemens.com> <4F59D3F1.1010901@cn.fujitsu.com> <4F59D5DB.1060702@siemens.com> In-Reply-To: <4F59D5DB.1060702@siemens.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: Jan Kiszka Cc: "eblake@redhat.com" , HATAYAMA Daisuke , "anderson@redhat.com" , "qemu-devel@nongnu.org" , "lcapitulino@redhat.com" At 03/09/2012 06:05 PM, Jan Kiszka Wrote: > On 2012-03-09 10:57, Wen Congyang wrote: >> At 03/09/2012 05:41 PM, Jan Kiszka Wrote: >>> On 2012-03-09 03:53, HATAYAMA Daisuke wrote: >>>> From: Wen Congyang >>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>> Date: Fri, 09 Mar 2012 10:26:56 +0800 >>>> >>>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>>>>> From: Wen Congyang >>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>>>>> >>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> 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. >>>>>>> >>>>>> >>>>>> The processing that adds part not referenced by page table to vmcore >>>>>> is meaningless for gdb. crash doesn't require it. So, it only >>>>>> complicates the current logic. >>>>> >>>>> If the paging mode is on, we can also use crash to analyze the vmcore. >>>>> As the comment methioned, the memory used by the 1st kernel may be not >>>>> referenced by the page table, so we neet this logic. >>>>> >>>> >>>> As I said several times, crash users don't use paging mode. Users of >>>> the paging mode is gdb only just as you say. So, the paging path needs >>>> to collect part referenced by page table only since the other part is >>>> invisible to gdb. >>> >>> If crash can work both with and without paging, it should be default >>> *on* to avoid writing cores that can later on only be analyzed with that >>> tool. Still not sure, though, if that changes the requirement on what >>> memory regions should be written in that mode. >> >> If this logic is not remvoed, crash can work both with and without paging. >> But the default value is 'off' now, because the option is '-p'. > > And this would be unfortunate if you do not want to use crash for > analyzing (I'm working on gdb python scripts which will make gdb - one > day - at least as powerful as crash). If paging mode has the same > information that non-paging mode has, I would even suggest to drop it. I donot have any knowledge about gdb python scripts. But is it OK to work without virtual address in PT_LOAD? Thanks Wen Congyang > > Jan >