From mboxrd@z Thu Jan 1 00:00:00 1970 From: bhsharma@redhat.com (Bhupesh Sharma) Date: Tue, 19 Jun 2018 17:28:15 +0530 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 James, On Tue, Jun 19, 2018 at 4:56 PM, James Morse wrote: > 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 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