[PATCH] arm64/mm: Introduce a variable to hold base address of linear region

[bhsharma@redhat.com (Bhupesh Sharma)]

Hi James,

On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@arm.com> 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@arm.com> 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 <yanjiang.jin@hxt-semitech.com>
>>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>>>> 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)
>>
>> {
>>
>> <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