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

[Wen Congyang]

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 <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.

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
>