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