>>> Simon Horman <horms@xxxxxxxxxxxx> 07.12.09 11:48 >>>
>On Mon, Dec 07, 2009 at 10:37:43AM +0000, Jan Beulich wrote:
>> While I can't determine the exact source location corresponding to the
>> crash (without the disassembly of the function), the page table walk
>> suggests this is a read from to the M2P table, which imposes a couple
>> of questions: How can this be a non-quad-word aligned access? Is the
>> access, if it makes sense, guarded by an mfn_valid() check? Is the
>> memory address corresponding to the M2P slot (mfn 0x3c20001) in a
>> physical memory hole?
>Any tips on how I could investigate those questions?
For the first two, you'd have to connect register/stack values to
source variables (by analyzing the disassembly) to understand what
access it is that causes the issue, and where the values come from.
Or alternatively just add debugging printk()-s to the function in
question (but that could be a lot of output depending on how long the
guest survives). Or whatever else debugging technique you like...
For the third, all it takes is looking up the memory map in the hypervisor
Xen-devel mailing list