On Thu, Oct 25, 2018 at 02:54:52AM +0530, Bhupesh Sharma wrote: > Since kernel version 4.19-rc5 (Commit 23c85094fe1895caefdd > ["proc/kcore: add vmcoreinfo note to /proc/kcore"]), '/proc/kcore' > contains a new PT_NOTE which carries the VMCOREINFO information. > > If the same is available, one should prefer the same to > retrieve 'PHYS_OFFSET' value exported by the kernel as this > is now the standard interface exposed by kernel for sharing > machine specific details with the user-land as per > the arm64 kernel maintainers (see [0]). > > Also 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. > > 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 vmcoreinfo inside '/proc/kcore' (if available). > - See the patch log for more details. > > Testing: > -------- > I tested this patchset on qualcomm-amberwing and huawei-taishan arm64 > boards for non-KALSR boot mode. Both display the same PHYS_OFFSET in > user-space as the value used by kernel after this patch. > > I will send a separate followup patch to fix the KASLR boot cases > (as the discussion on the same is in progress with the arm64 > kernel maintainers). > > [0] https://www.mail-archive.com/kexec@xxxxxxxxxxxxxxxxxxx/msg20300.html > > Bhupesh Sharma (2): > util_lib: Add functionality to read elf notes > arm64: Add support to read PHYS_OFFSET from '/proc/kcore' (if > available) > > kexec/arch/arm64/kexec-arm64.c | 73 ++ > util_lib/Makefile | 4 +- > vmcore-dmesg/vmcore-dmesg.c => util_lib/elf_info.c | 157 +++-- > util_lib/include/elf_info.h | 30 + > vmcore-dmesg/Makefile | 4 +- > vmcore-dmesg/vmcore-dmesg.c | 742 +-------------------- > 6 files changed, 219 insertions(+), 791 deletions(-) > copy vmcore-dmesg/vmcore-dmesg.c => util_lib/elf_info.c (88%) > create mode 100644 util_lib/include/elf_info.h Sorry for letting this slip through the cracks. Please let me know if this is still relevant. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
