On Wed, Jul 11, 2018 at 09:06:27PM +0530, Bhupesh Sharma wrote: > Hi James, > > On Wed, Jul 11, 2018 at 6:54 PM, James Morse <james.morse@xxxxxxx> wrote: > > Hi Bhupesh, > > > > (CC: +Omar) > > > > On 20/06/18 08:26, Bhupesh Sharma wrote: > >> On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang > >> <yanjiang.jin@xxxxxxxxxxxxxxxx> wrote: > >>>> From: Bhupesh Sharma [mailto:bhsharma@xxxxxxxxxx] > >>>> On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@xxxxxxx> wrote: > >>>>> I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section > >>>>> of /proc/kcore's ELF header. No special knowledge necessary, any > >>>>> elf-parser should be able to dump the values. > > > > [..] > >>>> I am working on fixes on the above lines for kernel and user-space tools (like > >>>> makedumpfile, crash-utility and kexec-tools). > >>>> > >>>> I will post some RFC patches on the same lines (or come back in case I get stuck > >>>> somewhere) shortly. > > > > I spotted this series from Omar: > > https://lkml.org/lkml/2018/7/6/866 > > > > Hopefully it does what you need? > > Thanks a lot for sharing this useful series. > > BTW, I am sorry for taking a long time to reply to this thread, but I > was reading some x86_64/ppc legacy code and also experimenting with > approaches in both user-space and kernel-space and have some > interesting updates. > > Just to recap, there are two separate issues we are seeing with arm64 > with user-space utilities which are used for debugging live systems or > crashed kernels: > > - Availability of PHYS_OFFSET in user-space (both for KASLR and > non-KASLR boot cases): > > I see two approaches to fix this issue: > 1. Fix inside Kernel: > a). See <https://www.spinics.net/lists/kexec/msg20847.html> for > background details. Having PHY_OFFSET added to the '/proc/kcore' as a > PT_NOTE (it is already added to vmcore as a NUMBER) would suffice. > > b). Omar's series add the vmcoreinfo to the kcore itself, so it would > be sufficient for the above case as well, since PHYS_OFFSET is already > added to the vmcoreinfo inside 'arch/arm64/kernel/machine_kexec.c': > > void arch_crash_save_vmcoreinfo(void) > { > <..snip..> > vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n", > PHYS_OFFSET); > <..snip..> > } > > c). This will help the cases where we are debugging a 'live' (or > running system). > > 2. Fix inside user-space: > a). See as an example a flaky reference implementation in > 'kexec-tools': See > <https://github.com/bhupesh-sharma/kexec-tools/commit/e8f920158ce57399c770c7160711a72fc740f1d6> > - Note that the calculation of 'ARM64_MEMSTART_ALIGN' value in > user-space is quite tricky (as is evident from the above > implementation and I took an easy route for my specific PAGE_SIZE and > VA_BITS combination). > > b). For some user-space tools like crash and makedumpfile, the > underlying macros like PMD_SHIFT etc have been added as arch-specific > code, so they can handle such implementation better. > > c). But this again means adding more arch specific code to user-space, > which probably not advisable. > > So, we will be better suited to go with a KERNEL fix for this case and > Omar's series should help. I will go ahead and give it a try for > arm64. Thanks, please do take a look. A Reviewed-by (or at least Tested-by) would help get it merged. Note that for my use case, the workaround I've been using for now is to get the physical address and size of vmcoreinfo from /sys/kernel/vmcoreinfo, then reading from that physical address in /proc/kcore (assuming that your kernel is new enough to fill in p_paddr in the /proc/kcore segments). _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
