On 29.08.2014 00:42, Andrew Cooper wrote: > On 28/08/2014 19:01, Stefan Bader wrote: >>>> So not much further... but then I think I know what I do next. Probably >>>> should >>>> have done before. I'll replace the WARN_ON in vmalloc that triggers by a >>>> panic >>>> and at least get a crash dump of that situation when it occurs. Then I can >>>> dig >>>> in there with crash (really should have thought of that before)... >>> <nods> I dug a bit in the code (arch/x86/xen/mmu.c) but there is nothing >>> there >>> that screams at me, so I fear I will have to wait until you get the crash >>> and get some clues from that. >> Ok, what a journey. So after long hours of painful staring at the code... >> (and btw, if someone could tell me how the heck one can do a mfn_to_pfn >> in crash, I really would appreaciate :-P) > > The M2P map lives in the Xen reserved virtual address space in each PV > guest, and forms part of the PV ABI. It is mapped read-only, in the > native width of the guest. > > 32bit PV (PAE) at 0xF5800000 > 64bit PV at 0xFFFF800000000000 > > This is represented by the MACH2PHYS_VIRT_START symbol from the Xen > public header files. You should be able to blindly construct a pointer > to it (if you have nothing better to hand), as it will be hooked into > the guests pagetables before execution starts. Therefore, > "MACH2PHYS_VIRT_START[(unsigned long)pfn]" ought to do in a pinch.
machine_to_phys_mapping is set to that address but its not mapped inside the crash dump. Somehow vtop in crash handles translations. I need to have a look at their code, I guess. Thanks, Stefan > > ~Andrew >
signature.asc
Description: OpenPGP digital signature
