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

[Dave Anderson]

----- 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 at suse.com>
> 

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.

Thanks,
  Dave