All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Tyler Baicar <tbaicar@codeaurora.org>
Cc: ard.biesheuvel@linaro.org, linux-efi@vger.kernel.org,
	linux-kernel@vger.kernel.org, jhugo@codeaurora.org,
	sgoel@codeaurora.org, timur@codeaurora.org
Subject: Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
Date: Wed, 28 Feb 2018 15:19:03 +0900	[thread overview]
Message-ID: <20180228061901.GJ6019@linaro.org> (raw)
In-Reply-To: <1519414953-5478-1-git-send-email-tbaicar@codeaurora.org>

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?
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.)

Are you using initrd with kexec?

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.
> 

  parent reply	other threads:[~2018-02-28  6:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 19:42 [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel Tyler Baicar
2018-02-23 19:42 ` [PATCH 1/2] efi/esrt: fix unsupported version initialization failure Tyler Baicar
2018-02-24  7:20   ` Dave Young
2018-03-08 16:11     ` Tyler Baicar
2018-03-08 18:00       ` Ard Biesheuvel
2018-03-08 18:15         ` Ard Biesheuvel
2018-03-08 18:34           ` Ard Biesheuvel
2018-02-23 19:42 ` [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap Tyler Baicar
2018-02-24  7:22   ` Dave Young
2018-02-24  8:03   ` Ard Biesheuvel
2018-02-26 15:06     ` Tyler Baicar
2018-02-26 15:07       ` Ard Biesheuvel
2018-02-28  6:19 ` AKASHI Takahiro [this message]
2018-02-28 15:39   ` [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel Jeffrey Hugo
2018-03-01  2:50     ` AKASHI Takahiro
2018-03-01 17:56       ` Tyler Baicar
2018-03-02  5:53         ` AKASHI Takahiro
2018-03-02 13:27           ` Tyler Baicar
2018-03-06  9:00             ` AKASHI Takahiro
2018-03-07 19:01               ` Tyler Baicar
2018-03-07 19:55               ` Ard Biesheuvel
2018-03-08 10:25                 ` AKASHI Takahiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180228061901.GJ6019@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=jhugo@codeaurora.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sgoel@codeaurora.org \
    --cc=tbaicar@codeaurora.org \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.