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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
