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 14:24:41 +0100

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

CR0 itself is one of the guest's resources. There's still the issue
whether to trust CR0 or not.

The assumption behind my idea is the host is running in a good
condition but the quest in a bad condition. So we can use qemu dump,
which is the host's feature.

Only checking if CR3 refers to page table correctly is considerably
complicated. CR3 can have any physical address. There's no hint such
as magic number to check it's invalid. So, to check if CR3 correctly
points at page table, the only way is to check if we can see the data
through actually performing paging for some virtual address. The
virtual address would be better if it's more typical one, but it tends
to be guest specific, and I think it's not suitable for qemu due to OS
dependency.
# Of course, this story is done out of the assumption that the data
# could be corrupted.

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

Also, it seems to me that the lacking feature of gdb used to dumpfile
compared with used to running guest is paging only. Paging is a
feature in architecture, which is unlikely to change in the
future. It's better in maintainability than introducing OS-level
dependency.

Thanks.
HATAYAMA, Daisuke