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

[james.morse@arm.com (James Morse)]

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,

James