From mboxrd@z Thu Jan 1 00:00:00 1970 From: james.morse@arm.com (James Morse) Date: Tue, 19 Jun 2018 12:26:09 +0100 Subject: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region In-Reply-To: References: <3a05cd0e-466e-4fb6-a78a-4b363e21aaab@arm.com> <92ff5220-f863-4edc-bc9f-bd802d2efa9c@arm.com> <20180619085541.GB13984@arm.com> <6860c284f1c74faa95edd6cf866ec80d@HXTBJIDCEMVIW02.hxtcorp.net> <20180619094045.GD13984@arm.com> <09260c7e-8b9d-bc3c-5bca-0fd75417f552@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Bhupesh, On 19/06/18 11:37, Bhupesh Sharma wrote: > On Tue, Jun 19, 2018 at 3:46 PM, James Morse 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 >>>> Cc: James Morse ; Bhupesh Sharma >>>> ; Mark Rutland ; Ard >>>> Biesheuvel ; Catalin Marinas >>>> ; Kexec Mailing List ; >>>> AKASHI Takahiro ; Bhupesh SHARMA >>>> ; linux-arm-kernel >>> 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) > > { > > > 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