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

[Jan Kiszka]

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.

Jan

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