From: Daniel Kiper <daniel.kiper@oracle.com>
To: Dave Anderson <anderson@redhat.com>
Cc: jgross@suse.com, Honglei Wang <honglei.wang@oracle.com>,
konrad wilk <konrad.wilk@oracle.com>,
ptesarik@suse.cz, kexec@lists.infradead.org,
xen-devel@lists.xenproject.org,
eric devolder <eric.devolder@oracle.com>,
crash-utility@redhat.com
Subject: Re: [Crash-utility] [PATCH] xen: Add support for domU with Linux kernel 3.19 and newer
Date: Mon, 29 May 2017 13:38:19 +0200 [thread overview]
Message-ID: <20170529113819.GL30364@olila.local.net-space.pl> (raw)
In-Reply-To: <2121155069.18928570.1495641388085.JavaMail.zimbra@redhat.com>
On Wed, May 24, 2017 at 11:56:28AM -0400, Dave Anderson wrote:
> ----- Original Message -----
> > crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for
> > dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility
> > support xen dom0 vmcores after linux kernel commit
> > 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear virtual
> > mapped sparse p2m list).
> >
> > This patch can be deemed as a subsequent and make this utility support Xen
> > PV domU dumpfiles again.
> >
> > Basically speaking, readmem() can't be used to read xen_p2m_addr associate
> > memory directly during m2p translation. It introduces infinite recursion.
> > Following call sequence shows the scenario, it comes from a section of
> > backtrace with only kvaddr, machine addr and mfn left as parameter:
> >
> > module_init()
> >
> > /* The first readmem() from module_init(). */
> > readmem(addr=0xffffffffa02fe4a0)
> >
> > /* readmem() needs physical address, so calls kvtop(). */
> > kvtop(kvaddr=0xffffffffa02fe4a0)
> > x86_64_kvtop(kvaddr=ffffffffa02fe4a0)
> >
> > /* Calculate physical address by traversing page tables. */
> > x86_64_kvtop_xen_wpt(kvaddr=0xffffffffa02fe4a0)
> >
> > /*
> > * x86_64_kvtop_xen_wpt() is going to traverse the page table to
> > * get the physical address for 0xffffffffa02fe4a0. So, at first it
> > * is needed to translate the pgd from machine address to physical
> > * address. So invoke xen_m2p() here to do the translation. 0x58687f000
> > * is the pgd machine address in x86_64_kvtop_xen_wpt() and is needed
> > * to be translated to its physical address.
> > */
> > xen_m2p(machine=0x58687f000)
> > __xen_m2p(machine=0x58687f000, mfn=0x58687f)
> >
> > /*
> > * __xen_m2p() is going to search mfn 0x58687f in p2m VMA which starts
> > * at VMA 0xffffc900001cf000. It compares every mfn stored in it with
> > * 0x58687f. Once it's proved 0x58687f is one mfn in the p2m, its offset
> > * will be used to calculate the pfn.
> > *
> > * readmem() is invoked by __xen_m2p() to read the page from VMA
> > * 0xffffc900001cf000 here.
> > */
> > readmem(addr=0xffffc900001cf000)
> >
> > /*
> > * readmem() needs physical address of 0xffffc900001cf000 to make the
> > * reading done. So it invokes kvtop() to get the physical address.
> > */
> > kvtop(kvaddr=0xffffc900001cf000)
> > x86_64_kvtop(kvaddr=0xffffc900001cf000)
> >
> > /* It needs to calculate physical address by traversing page tables. */
> > x86_64_kvtop_xen_wpt(kvaddr=0xffffc900001cf000)
> >
> > /*
> > * 0x581b7e000 is the machine address of pgd need to be translated here.
> > * The mfn is calculated in this way at x86_64_kvtop_xen_wpt():
> > *
> > * pml4 = ((ulong *)machdep->machspec->pml4) + pml4_index(kvaddr);
> > * pgd_paddr = (*pml4) & PHYSICAL_PAGE_MASK;
> > *
> > * The kvaddr 0xffffc900001cf000 here is quite different from the one
> > * above, so the machine address of pgd is not the same one. And this
> > * pgd is the one we use to access the VMA of p2m table.
> > */
> > xen_m2p(machine=0x581b7e000)
> > __xen_m2p(machine=0x581b7e000, mfn=0x581b7e)
> >
> > /*
> > * Looking for mfn 0x581b7e in the range of p2m page which starts at
> > * VMA 0xffffc900001f5000.
> > */
> > readmem(addr=0xffffc900001f5000)
> >
> > /* Need physical address of VMA 0xffffc900001f5000 as same reason above. */
> > kvtop(kvaddr=0xffffc900001f5000)
> > x86_64_kvtop(kvaddr=0xffffc900001f5000)
> >
> > /* Need to traverse page tables to calculate physical address for it. */
> > x86_64_kvtop_xen_wpt(kvaddr=0xffffc900001f5000)
> >
> > /*
> > * Unfortunately, machine address 0x581b7e000 have to be translated again.
> > * Endless loop starts from here.
> > */
> > xen_m2p(machine=0x581b7e000)
> > __xen_m2p(machine=0x581b7e000, mfn=0x581b7e)
> > readmem(addr=0xffffc900001f5000)
> >
> > Fortunately, PV domU p2m mapping is also stored at xd->xfd + xch_index_offset
> > and organized as struct xen_dumpcore_p2m. We have a chance to read the p2m
> > stuff directly from there, and then we avoid the loop above.
> >
> > So, this patch implements a special reading function read_xc_p2m() to extract
> > the mfns from xd->xfd + xch_index_offset. This function does not need to read
> > mfns from p2m VMA like readmem() does, so, we avoid the endless loop introduced
> > by the address translation.
> >
> > Signed-off-by: Honglei Wang <honglei.wang@oracle.com>
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> Queued for crash-7.2.0:
>
> https://github.com/crash-utility/crash/commit/5c52842a58a2602dba81de71831af98b2b53c6e0
Wow, Dave, you are fast! Thanks a lot!
Honglei, congrats! Thanks for doing the work!
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2017-05-29 11:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 7:13 [Crash-utility] [PATCH] xen: Add support for domU with Linux kernel 3.19 and newer Honglei Wang
2017-05-24 15:56 ` Dave Anderson
2017-05-25 1:32 ` Honglei Wang
2017-05-29 11:38 ` Daniel Kiper [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170529113819.GL30364@olila.local.net-space.pl \
--to=daniel.kiper@oracle.com \
--cc=anderson@redhat.com \
--cc=crash-utility@redhat.com \
--cc=eric.devolder@oracle.com \
--cc=honglei.wang@oracle.com \
--cc=jgross@suse.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=ptesarik@suse.cz \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox