Hi Yanjiang, On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang <yanjiang.jin@xxxxxxxxxxxxxxxx> wrote: > Hi James, Bhupesh, > > If /proc/kcore always exists in kexec/kdump, I think this issue can be fixed easily. But it requires that Kexec/kdump have to rely on " CONFIG_PROC_KCORE=y". > I am not sure if we can persuade Kexec-tools community to accept this. Most distributions like Ubuntu and Fedora already enable CONFIG_PROC_KCORE by default, to support user-space tools like crash-utility and makedumpfile which can be used for 'live' debugging of a primary kernel (without the requirement of being in the secondary or crash kernel). For such cases. '/proc/kcore' and 'vmlinux' are the only available sources for PT_NOTE/PT_LOAD segments and kernel symbols respectively. Since we need to support all such existing user-space utilities (which work well with other archs like x86 and ppc64), we need to have a solution which works without modifying most of them - the rest (like kexec-tools) can be easily modified to follow the same approach. I would share some patches soon on the same lines both for kernel and user-space. Thanks, Bhupesh >> -----Original Message----- >> From: Bhupesh Sharma [mailto:bhsharma@xxxxxxxxxx] >> Sent: 2018年6月19日 19:58 >> To: James Morse <james.morse@xxxxxxx> >> Cc: Jin, Yanjiang <yanjiang.jin@xxxxxxxxxxxxxxxx>; Will Deacon >> <will.deacon@xxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; Ard >> Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Catalin Marinas >> <catalin.marinas@xxxxxxx>; Kexec Mailing List <kexec@xxxxxxxxxxxxxxxxxxx>; >> AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>; Bhupesh SHARMA >> <bhupesh.linux@xxxxxxxxx>; linux-arm-kernel <linux-arm- >> kernel@xxxxxxxxxxxxxxxxxxx> >> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of >> linear region >> >> Hi James, >> >> On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@xxxxxxx> wrote: >> > Hi Bhupesh, >> > >> > On 19/06/18 11:37, Bhupesh Sharma wrote: >> >> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@xxxxxxx> >> wrote: >> >>> On 19/06/18 10:57, Jin, Yanjiang wrote: >> >>>>> -----Original Message----- >> >>>>> From: Will Deacon [mailto:will.deacon@xxxxxxx] >> >>>>> Sent: 2018年6月19日 17:41 >> >>>>> To: Jin, Yanjiang <yanjiang.jin@xxxxxxxxxxxxxxxx> >> >>>>> Cc: James Morse <james.morse@xxxxxxx>; Bhupesh Sharma >> >>>>> <bhsharma@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; Ard >> >>>>> Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Catalin Marinas >> >>>>> <catalin.marinas@xxxxxxx>; Kexec Mailing List >> >>>>> <kexec@xxxxxxxxxxxxxxxxxxx>; AKASHI Takahiro >> >>>>> <takahiro.akashi@xxxxxxxxxx>; Bhupesh SHARMA >> >>>>> <bhupesh.linux@xxxxxxxxx>; linux-arm-kernel <linux-arm- >> >>>>> kernel@xxxxxxxxxxxxxxxxxxx> >> >>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base >> >>>>> address of linear region >> > >> >>>>>>>> It is hard to know all above in kexec-tools now. Originally I >> >>>>>>>> planned to read memstart_addr's value from "/dev/mem", but >> >>>>>>>> someone thought not all Kernels enable "/dev/mem", we'd better >> >>>>>>>> find a more generic approach. So we want to get some >> >>>>>>>> suggestions from ARM kernel >> >>>>> community. >> >>>>>>>> Can we export this variable in Kernel side through sysconf() or >> >>>>>>>> other similar methods? Or someone can provide an effect way to >> >>>>>>>> get memstart_addr's value? >> >>>>>>> >> >>>>>>> I thought the suggestion from James was to expose this via an >> >>>>>>> ELF NOTE in kcore and vmcore (or in the header directly if >> >>>>>>> that's possible, but I'm >> >>>>> not sure about it)? >> >>>>>> >> >>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a >> >>>>>> must-have, so we can't depend on it. >> >>>>> >> >>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps. >> >>>>> >> >>>>>> On the other hand, phys_to_virt() is called during generating >> >>>>>> vmcore in Kexec-tools, vmcore also can't help this issue. >> >>>>> >> >>>>> I don't understand this part. If you have the vmcore in your hand, >> >>>>> why can't you grok the pv offset from the note and use that in >> phys_to_virt()? >> >>>> >> >>>> It is a chicken-and-egg issue. >> >>>> phys_to virt() is for crashdump setup. To generate vmcore, we must >> >>>> call phys_to_virt(). At this point, no vmcore exists. >> >>> >> >>> Its needed for the parts of the ELF header that kexec-tools >> >>> generates at kdump load time? >> >>> >> >>> So adding this pv_offset to the key=value data >> >>> crash_save_vmcoreinfo_init() saves isn't available early enough? >> > >> >> Yes, one case where it is not actually available early enough for >> >> makedumpfile usage is if we are determining the PT_NOTE contents from >> >> the '/proc/kcore' on a 'live' system >> > >> >> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t >> >> vmcoreinfo_len) >> >> >> >> { >> >> >> >> <snip..> >> >> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET; >> >> >> >> } >> > >> > You are trying to read the vmcoreinfo through /proc/kcore given >> > knowledge of its physical address. >> > >> > 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. >> > >> > >> >> Now the problem at hand is to determine the offset at which the >> >> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume >> >> that when you mentioned above and earlier about adding this pair to >> >> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we >> >> can have 'n' number of PT_LOAD segments. >> > >> > It looks like there is already a NOTE section with core info in there: >> > | # readelf -l /proc/kcore >> > | >> > | Elf file type is CORE (Core file) >> > | Entry point 0x0 >> > | There are 16 program headers, starting at offset 64 >> > | >> > | Program Headers: >> > | Type Offset VirtAddr PhysAddr >> > | FileSiz MemSiz Flags Align >> > | NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000 >> > | 0x0000000000001114 0x0000000000000000 0x0 >> > >> > I assume we can add more notes without breaking the existing user... >> > >> > (and it looks like there are some broken __pa(kernel symbol) users in there. >> >> Thanks for your inputs. >> >> 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. >> >> Thanks, >> Bhupesh > > > > This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you. > > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
