Hi Bhupesh,
On 19/06/18 11:37, Bhupesh Sharma wrote:
> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.mo...@arm.com> wrote:
>> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>>> -----Original Message-----
>>>> From: Will Deacon [mailto:will.dea...@arm.com]
>>>> Sent: 2018年6月19日 17:41
>>>> To: Jin, Yanjiang <yanjiang....@hxt-semitech.com>
>>>> Cc: James Morse <james.mo...@arm.com>; Bhupesh Sharma
>>>> <bhsha...@redhat.com>; Mark Rutland <mark.rutl...@arm.com>; Ard
>>>> Biesheuvel <ard.biesheu...@linaro.org>; Catalin Marinas
>>>> <catalin.mari...@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>> AKASHI Takahiro <takahiro.aka...@linaro.org>; Bhupesh SHARMA
>>>> <bhupesh.li...@gmail.com>; linux-arm-kernel <linux-arm-
>>>> ker...@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,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
