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

[HATAYAMA Daisuke]

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.

  - 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