[PATCH] arm64/mm: Introduce a variable to hold base address of linear region

Jin, Yanjiang yanjiang.jin at hxt-semitech.com
Tue Jun 19 19:16:59 PDT 2018


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.

Thanks,
Yanjiang

> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
> Sent: 2018年6月19日 19:58
> To: James Morse <james.morse at arm.com>
> Cc: Jin, Yanjiang <yanjiang.jin at hxt-semitech.com>; Will Deacon
> <will.deacon at arm.com>; Mark Rutland <mark.rutland at arm.com>; Ard
> Biesheuvel <ard.biesheuvel at linaro.org>; Catalin Marinas
> <catalin.marinas at arm.com>; Kexec Mailing List <kexec at lists.infradead.org>;
> AKASHI Takahiro <takahiro.akashi at linaro.org>; Bhupesh SHARMA
> <bhupesh.linux at gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> 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 at arm.com> 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 at arm.com>
> wrote:
> >>> On 19/06/18 10:57, Jin, Yanjiang wrote:
> >>>>> -----Original Message-----
> >>>>> From: Will Deacon [mailto:will.deacon at arm.com]
> >>>>> Sent: 2018年6月19日 17:41
> >>>>> To: Jin, Yanjiang <yanjiang.jin at hxt-semitech.com>
> >>>>> Cc: James Morse <james.morse at arm.com>; Bhupesh Sharma
> >>>>> <bhsharma at redhat.com>; Mark Rutland <mark.rutland at arm.com>; Ard
> >>>>> Biesheuvel <ard.biesheuvel at linaro.org>; Catalin Marinas
> >>>>> <catalin.marinas at arm.com>; Kexec Mailing List
> >>>>> <kexec at lists.infradead.org>; AKASHI Takahiro
> >>>>> <takahiro.akashi at linaro.org>; Bhupesh SHARMA
> >>>>> <bhupesh.linux at gmail.com>; linux-arm-kernel <linux-arm-
> >>>>> kernel at lists.infradead.org>
> >>>>> 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.




More information about the kexec mailing list