[Crash-utility] dom0 analysis for IA64
Dave Anderson
anderson at redhat.com
Thu May 10 19:27:34 UTC 2007
Itsuro ODA wrote:
> Hi Dave,
>
> The attached patch enables to analyze dom0 linux from
> whole memory dump on IA64. (for crash-4.0-4.1)
> It is just quick hack.
> (I was asked from IA64 Xen developers and made it.)
>
> Each domain manages own machine memory by domain.arch.mm.pgd
> in IA64. It is 3-level page table.
> I thougnt the mfn of domain.arch.mm.pgd can be regarded as
> p2m_mfn.
>
> I intended to modify as less existent code as possible.
> But this patch is a bit tricky. And the memory usage is
> large if the machine memory layout is sparse.
> (maybe xen_kdump_p2m should be prepare for each arch ?)
>
> Would you consider to support dom0 analysis for IA64 ?
>
> I prepared two sample dumps. Please find from the following
> URLs.
>
> 1) http://people.valinux.co.jp/~oda/20070510-sample-dump-1.tar
> contents:
> - vmcore.gz
> This is taken by a hard assist dump. netdump style ELF vmcore.
> So XEN_ELFNOTE_CRASH_INFO does not exist.
> - vmcore.ka.gz
> It is coverted to kdump style and added XEN_ELFNOTE_CRASH_INFO
> manually.
> - vmlinux.debug.gz
> for dom0 analysis
> - xen-syms-2.6.18-8.el5.gz
> for xencrash
>
> To get p2m_mfn, xencrash's doms command is usefull.
> --------------------------------------------------------------------------
> # crash xen-syms-2.6.18-8.el5 vmcore
> ...
> crash> doms
> DID DOMAIN ST T MAXPAGE TOTPAGE VCPU SHARED_I P2M_MFN
> 32753 f000000007ac8080 RU O 0 0 0 0 ----
> 32754 f000000007acc080 RU X 0 0 0 0 ----
> > 32767 f000000007ff8080 RU I 0 0 4 0 ----
> 0 f000000007aa4080 RU 0 10000 fc28 1 f000000007a88000 1abb7
> >* 1 f000000007a78080 RU U 10603 10603 3 f000000007a5c000 1a909
> crash>
> ----------------------------------------------------------------------------
>
> Then normal crash session with --p2m_mfn option.
> ----------------------------------------------------------------------------
> # crash --p2m_mfn=1abb7 vmlinux.debug vmcore
> ...
> ----------------------------------------------------------------------------
>
> vmcore.ka has XEN_ELFNOTE_CRASH_INFO. so --p2m_mfn option not need.
> ----------------------------------------------------------------------------
> # crash vmlinux.debug vmcore.ka
> ...
> ----------------------------------------------------------------------------
>
> --p2m_mfn option is effective only if a vmcore has XEN_ELFNOTE_CRASH_INFO
> now.
> I think specifying --p2m_mfn option is regarded as the vmcore is
> XEN_CORE_DUMPFILE(). The patch supports this.
> I think it is necessary for dumps which does not have
> XEN_ELFNOTE_CRASH_INFO such as above sample.
>
OK, I finally got these all downloaded. However, the xen-syms
binary in the "sample-1" directory has no debug data:
# file xen-syms-2.6.18-8.el5
xen-syms-2.6.18-8.el5: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically linked, stripped
#
And I see that check_netdump_xen() is only called if the
netdump (?) vmcore is used, since it needs the --p2m_mfn
argument. I have no idea where check_kdump_xen() would
apply?
In any case, I really prefer not to support whatever that
first "hard assist dump. netdump style ELF" vmcore file.
(What is that???)
I don't see why the support for dom0 ia64 kdumps should
be any different than for x86 and x86_64, both of which
have XEN_ELFNOTE_CRASH_INFO notes containing the p2m mfn
value.
Therefore, the check_netdump_xen() and check_kdump_xen()
can be thrown out, and all that is really required is the
implementation of ia64_xen_kdump_p2m_create() for the vmlinux
side. But it will still need a fix to deal with that
over-sized (?) 512k p2m_frame list. Can you look into fixing
that?
Also, I don't quite understand the changes to xen_kdump_p2m().
The first (generic) part is probably a safe thing to do:
+ if (mfn_idx >= xkd->p2m_frames)
+ return P2M_FAILURE;
But if the above code is put into place, how would it
be possible for the resultant mfn_frame to be 0?
+ #ifdef IA64
+ if (mfn_frame == 0)
+ return P2M_FAILURE;
+ #endif
And I don't understand this part at all:
+ #ifdef IA64
+ if (!(*mfnptr & 0x1))
+ return P2M_FAILURE;
+ paddr = *mfnptr & _PFN_MASK;
+ #else
+ paddr = (physaddr_t)PTOB((ulonglong)(*mfnptr));
+ #endif
Although, after putting in a debug printf of what the mfns
actually look like on an ia64, I guess I see why it's
necessary.
On x86 and x86_64, the mfnptr points to a simple mfn value.
But on the ia64, I see mfns that look like 81000007bf3c761,
where the "1-bit" is always set. And you don't shift the
mfn value like x86/x86_64 do. Can you help me understand
the format of the ia64 mfns? In other words, what part of a
value such as 81000007bf3c761 is the actual mfn? Are there
page flags or something in the lower bits of the number?
Thanks,
Dave
>
> 2) http://people.valinux.co.jp/~oda/20070510-sample-dump-2.tar
> contents:
> - vmcore.tiger.iomem_machine.gz
> taken by Xen kdump
> - vmlinux-xen-ia64.bz2
> - xen-syms-ia64.bz2
>
> I asked Xen kdump developper (simon at valinux) to add "p2m_mfn" to
> XEN_ELFNOTE_CRASH_INFO.
> So this change of Xen kdump is not open yet.
> If this is OK for crash, it will be commited.
>
> Thanks.
> --
> Itsuro ODA <oda at valinux.co.jp>
>
> ------------------------------------------------------------------------------------------------------------------------
> Name: diff-20070510
> diff-20070510 Type: unspecified type (application/octet-stream)
> Encoding: base64
>
> ------------------------------------------------------------------------------------------------------------------------
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070510/80eae55e/attachment.htm>
More information about the Crash-utility
mailing list