From: Jan Kiszka <jan.kis...@siemens.com>
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.
- If guest machine is in catastrophic state, its memory data could
be corrupted. Then, we cannot trust such corrupted page table.
# 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.
Thanks.
HATAYAMA, Daisuke
