Re: [Crash-utility] [PATCH] Do not create arch-specific p2m mapping for ELF xen dumps

----- Original Message ----- > Hello Dave, > > Let me send you a cleanup/fix for Xen DomU dumps. > > When opening a Xen DomU dump without auto-translated addresses (e.g. > from an x86_64 PV domain), a mapping between physical and machine > pages is needed. An xc_core dump file does not contain this mapping, > so it must be created by arch-specific code from the dumped data. > > This (and only this) is the job of the machdep->xendump_p2m_create > callback, which is called if the XC_CORE_P2M_CREATE flag is set. ELF > files contain the mapping in a separate section (".xen_p2m"), so this > arch-specific code is not needed and should not be run. > > On the other hand, XC_CORE_P2M_CREATE also triggers the initialization > of the elf_index_pfn array. I believe this should be in fact controlled > by XC_CORE_PFN_CREATE, because the flag is not used for anything else. > > I found this issue thanks to a Xen DomU ELF dump file that contained an > invalid CR3 value, which could not be used to translate kvaddr to maddr. > Without the patch, session initialization fails with these messages: > > crash: cannot find mfn 0 (0x0) in page index > > crash: cannot read/find pud page > > Signed-off-by: Petr Tesarik <ptesarik(a)suse.com&gt; > Hi Petr, This looks good. Can you help me come up with a succinct blurb for the changelog? From my test output, it's now obvious that the gathering of the p2m_frames/p2m_frame_index_list is unnecessary in the case of PV kernel dumps (correct?).

And you ran into a situation in which an invalid CR3 in the header caused the (unnecessary) p2m frame-gathering to fail, and as a result the crash session itself was aborted.