Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping

[Jan Kiszka]

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 <address@hidden>
>>> 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 <address@hidden>
>>>>> 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 <address@hidden>
>>>>>>> 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 <address@hidden>
>>>>>>>>> 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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux