Messages in this thread | | | Subject | Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel | From | Jeffrey Hugo <> | Date | Wed, 28 Feb 2018 08:39:42 -0700 |
| |
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
> > Thanks, > -Takahiro AKASHI > > >> This causes an early ioremap leak because >> the memory allocated for 'va' is never unmapped. So first fix that error >> case to properly unmap 'va' before returning. >> >> This still leaves ESRT unable to initialize in the kexec'd kernel, so now >> mark the ESRT memory block as nomap so that this memory is not treated as >> System RAM. With this change I'm able to see that the ESRT data is not >> overwritten when running a kexec'd kernel. >> >> Tyler Baicar (2): >> efi/esrt: fix unsupported version initialization failure >> efi/esrt: mark ESRT memory region as nomap >> >> drivers/firmware/efi/esrt.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> -- >> 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. >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
-- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
| |