Hello,

On 2/28/2018 9:50 PM, AKASHI Takahiro wrote:
> Hi,
>
> On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote:
>> On 2/27/2018 11:19 PM, AKASHI Takahiro wrote:
>>> Tyler,
>>>
>>> # I missed catching your patch as its subject doesn't contain arm64.
>>>
>>> On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote:
>>>> Currently on arm64 ESRT memory does not appear to be properly blocked off.
>>>> Upon successful initialization, ESRT prints out the memory region that it
>>>> exists in like:
>>>>
>>>> esrt: Reserving ESRT space from 0x000000000a4c1c18 to 0x000000000a4c1cf0.
>>>>
>>>> But then by dumping /proc/iomem this region appears as part of System RAM
>>>> rather than being reserved:
>>>>
>>>> 08f10000-0deeffff : System RAM
>>>>
>>>> This causes issues when trying to kexec if the kernel is relocatable. When
>>>> kexec tries to execute, this memory can be selected to relocate the kernel to
>>>> which then overwrites all the ESRT information. Then when the kexec'd kernel
>>>> tries to initialize ESRT, it doesn't recognize the ESRT version number and
>>>> just returns from efi_esrt_init().
>>> I'm not sure what is the root cause of your problem.
>>> Do you have good confidence that the kernel (2nd kernel image in this case?)
>>> really overwrite ESRT region?
>> According to my debug, yes.
>> Using JTAG, I was able to determine that the ESRT memory region was getting
>> overwritten by the secondary kernel in
>> kernel/arch/arm64/kernel/relocate_kernel.S - specifically the "copy_page"
>> line of arm64_relocate_new_kernel()
>>
>>> To my best knowledge, kexec is carefully designed not to do such a thing
>>> as it allocates a temporary buffer for kernel image and copies it to the
>>> final destination at the very end of the 1st kernel.
>>>
>>> My guess is that kexec, or rather kexec-tools, tries to load the kernel image
>>> at 0x8f80000 (or 0x9080000?, not sure) in your case. It may or may not be
>>> overlapped with ESRT.
>>> (Try "-d" option when executing kexec command for confirmation.)
>> With -d, I see
>>
>> get_memory_ranges_iomem_cb: 0000000009611000 - 000000000e5fffff : System RAM
>>
>> That overlaps the ESRT reservation -
>> [ 0.000000] esrt: Reserving ESRT space from 0x000000000b708718 to
>> 0x000000000b7087f0
>>
>>> Are you using initrd with kexec?
>> Yes
> To make the things clear, can you show me, if possible, the followings:
I have attached all of these:
> * dmesg
dmesg.txt: Main kernel dmesg logs which shows ESRT enabling properly
kexec_dmesg.txt: Kexec'd kernel dmesg logs showing ESRT invalid version and the 
memory leak warning
> * /proc/iomem
iomem.txt
> * the output from "kexec -d", particularly the last part like
>      kexec_load: entry = 0x411d7660 flags = 0xb70000
>      nr_segments = 3
>      segment[0].buf   = 0xffff86613010
>      segment[0].bufsz = 0x10e9b48
>      segment[0].mem   = 0x40080000
>      segment[0].memsz = 0x1156000
>      segment[1].buf   = 0xffff86211010
>      segment[1].bufsz = 0x20e
>      segment[1].mem   = 0x411d6000
>      segment[1].memsz = 0x1000
>      segment[2].buf   = 0x5045420
>      segment[2].bufsz = 0x31b8
>      segment[2].mem   = 0x411d7000
>      segment[2].memsz = 0x4000
kexec_output.txt

Thanks,
Tyler

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.