From: Simon Horman <horms@verge.net.au>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
Vadim.Lomovtsev@cavium.com,
Bhupesh SHARMA <bhupesh.linux@gmail.com>,
kexec mailing list <kexec@lists.infradead.org>
Subject: Re: [PATCH v2 0/2] kexec-tools/arm64: Add support to read PHYS_OFFSET from kcore
Date: Wed, 9 Jan 2019 13:29:09 +0100 [thread overview]
Message-ID: <20190109122909.2ev4skeyrbre433m@verge.net.au> (raw)
In-Reply-To: <CACi5LpMQirN+QwWWxxvWq3eFhzy-C3TT+gS3v=r_Hbba4Lsitw@mail.gmail.com>
On Mon, Jan 07, 2019 at 04:22:49PM +0530, Bhupesh Sharma wrote:
> Hi Simon,
>
> On Thu, Dec 20, 2018 at 4:52 PM Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> > Changes from v1:
> > ---------------
> > - Added the support for older kernels, where we determine the
> > PHYS_OFFSET value from PT_LOAD segments inside 'kcore'.
> > - Improved commit logs since v1.
> >
> > On certain arm64 platforms, it has been noticed that due
> > to a hole at the start of physical ram exposed to kernel
> > (i.e. it doesn't start from address 0), the kernel still
> > calculates the 'memstart_addr' kernel variable as 0.
> >
> > Whereas the SYSTEM_RAM or IOMEM_RESERVED range in '/proc/iomem'
> > would carry a first entry whose start address is non-zero
> > (as the physical ram exposed to the kernel starts from a
> > non-zero address).
> >
> > In such cases, if we rely on '/proc/iomem' entries to
> > calculate the phys_offset, then we will have mismatch
> > between the user-space and kernel space 'PHYS_OFFSET'
> > value. The present 'kexec-tools' code does the same
> > in 'get_memory_ranges_iomem_cb()' function when it makes
> > a call to 'set_phys_offset()'. This can cause the vmcore
> > generated via 'kexec-tools' to miss the last few bytes as
> > the first '/proc/iomem' starts from a non-zero address.
> >
> > Please see [0] for the original bug-report from Yanjiang Jin.
> >
> > This patchset tries to fix the same.
> >
> > Details about the patches in this series:
> > ----------------------------------------
> > PATCH 1/2 ->
> >
> > - Tries to move the elf read functionality from 'vmcore-dmesg.c' to
> > a new utility library named 'elf_info.c', so that subsequent patches
> > can use the same.
> > - See the patch log for more details.
> >
> > PATCH 2/2 ->
> > - Implements the actual functionality of reading the PHYS_OFFSET for arm64
> > platforms from the kcore (either VMCOREINFO PT_NOTE inside 'kcore'
> > or from the PT_LOAD segments inside 'kcore').
> > - See the patch log for more details.
> >
> > [0] https://www.spinics.net/lists/kexec/msg20618.html
> >
> > Bhupesh Sharma (2):
> > util_lib: Add functionality to read elf notes
> > arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or
> > pt_load (if available)
> >
> > kexec/arch/arm64/kexec-arm64.c | 194 +++++-
> > kexec/arch/arm64/kexec-arm64.h | 15 +-
> > util_lib/Makefile | 4 +-
> > vmcore-dmesg/vmcore-dmesg.c => util_lib/elf_info.c | 193 ++++--
> > util_lib/include/elf_info.h | 35 +
> > vmcore-dmesg/Makefile | 4 +-
> > vmcore-dmesg/vmcore-dmesg.c | 742 +--------------------
> > 7 files changed, 386 insertions(+), 801 deletions(-)
> > copy vmcore-dmesg/vmcore-dmesg.c => util_lib/elf_info.c (86%)
> > create mode 100644 util_lib/include/elf_info.h
> >
> > --
> > 2.7.4
>
> Ping. Since this fixes a pending known issue on arm64 boards (both for
> KASLR and non-KASLR boot cases) can we please pick this patch-set for
> upstream kexec-tools.
Thanks, and sorry for the delay.
I have applied this series.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2019-01-09 12:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 11:22 [PATCH v2 0/2] kexec-tools/arm64: Add support to read PHYS_OFFSET from kcore Bhupesh Sharma
2018-12-20 11:22 ` [PATCH v2 1/2] util_lib: Add functionality to read elf notes Bhupesh Sharma
2018-12-20 11:22 ` [PATCH v2 2/2] arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or pt_load (if available) Bhupesh Sharma
2019-01-07 10:52 ` [PATCH v2 0/2] kexec-tools/arm64: Add support to read PHYS_OFFSET from kcore Bhupesh Sharma
2019-01-09 12:29 ` Simon Horman [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=20190109122909.2ev4skeyrbre433m@verge.net.au \
--to=horms@verge.net.au \
--cc=Vadim.Lomovtsev@cavium.com \
--cc=bhsharma@redhat.com \
--cc=bhupesh.linux@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=takahiro.akashi@linaro.org \
--cc=yanjiang.jin@hxt-semitech.com \
/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