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

[Jan Kiszka]

On 2012-03-09 13:53, HATAYAMA Daisuke wrote:
> From: Jan Kiszka <address@hidden>
> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping
> Date: Fri, 09 Mar 2012 11:06:30 +0100
> 
>> On 2012-03-09 11:05, Jan Kiszka wrote:
>>>>> 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.
>>
>> Err, with "it" = "non-paging mode".
>>
>> Jan
> 
> Paging at default is not good idea. Performing paging in qemu has risk.
> 
>   - Guest machine is not always in the state where paging mode is
>     enabled. Also, CR3 doesn't always refer to page table.

That's detectable and means physical == linear address.

> 
>   - If guest machine is in catastrophic state, its memory data could
>     be corrupted. Then, we cannot trust such corrupted page table.

OK, here I agree.

> 
>     # In this point, managing PT_LOAD program headers based on such
>     # potencially corruppted data has risk.
> 
> The idea of yours that performing paging in debugger side is better
> than doing in qemu.

Another alternative is to add guest-awareness to the dump code. If we
detect (or get told) that the target is a Linux kernel, at least the
linear kernel mapping can be written reliably.

But also the fact that there can be as many different page tables as
active processors means that paging likely needs a second thought and
more awareness of the debugger.

Jan

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