All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.