----- Original Message ----- > On Fri, May 20, 2016 at 03:06:39PM -0400, Dave Anderson wrote: > > > > > > Hi Takahiro, > > > > Welcome to the mailing list -- you are a most valuable addition. > > > > To others in the list, Takahiro and I have been communicating offline > > for a couple weeks, and I convinced him to join us. He works on both > > kexec-tools and the crash utility for Linaro on the ARM64 architecture. > > If you are unaware, in Linux 4.6 there was a major change in the ARM64 > > virtual memory layout, complicated by the layering of KASLR on top of it. > > The new VM has broken crash utility support completely, and Takahiro is > > tackling both. > > > > My comments and questions on the v1 patch follow... > > > > ----- Original Message ----- > > > Hi, > > > > > > This patch is still rough-edged, but please review it and > > > any comments are very welcome. > > > I will try to fix the known issues before I submit a new > > > version of kexec/kdump patch for v4.7 merge window. > > > > > > Thanks, > > > -Takahiro AKASHI > > > > > > ===8<=== > > > >From fdc7c881d98ef00ed1ff38a058b4913a1d5bcda6 Mon Sep 17 00:00:00 2001 > > > From: AKASHI Takahiro <takahiro.aka...@linaro.org> > > > Date: Mon, 16 May 2016 17:31:55 +0900 > > > Subject: [PATCH v1] arm64: fix kernel memory map handling for > > > kaslr-enabled > > > kernel > > > > > > In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start > > > address of the kernel image can be randomized if CONFIG_RANDOMIZE_BASE is > > > enabled. > > > Even worse, the kernel image is no more mapped in the linear mapping, but > > > in vmalloc area (i.e. below PAGE_OFFSET). > > > > > > Now, according to the kernel's memory.h, converting a virtual address to > > > a physical address should be done like below: > > > > > > phys_addr_t __x = (phys_addr_t)(x); \ > > > __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \ > > > (__x - kimage_voffset); }) > > > > > > Please note that PHYS_OFFSET is no more equal to the start address of > > > the first usable memory block in SYSTEM RAM due to the fact mentioned > > > above. > > > > So it is no longer possible to use /proc/iomem if KASLR is enabled > > on a live system? That being the case, we need a way for root to > > be able to determine what it is for live system analysis. > > Now that PHYS_OFFSET is defined as "memstart_addr", we can get the value > if we can access this symbol (on a live system).
When PHYS_OFFSET/memstart_addr is bumped up from the actual base of physical memory, is the physical memory below it no longer used/accessible? Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility