From: "Zhang, Jonathan Zhixiong" <zjzhang@codeaurora.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Matt Fleming <matt.fleming@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linaro-acpi@lists.linaro.org
Subject: Re: [PATCH 1/2] efi: arch, x86: arch, ia64: rearrange EFI memmap related functions
Date: Wed, 27 May 2015 12:35:49 -0700 [thread overview]
Message-ID: <55661C95.5010200@codeaurora.org> (raw)
In-Reply-To: <20150527123103.GC3030@codeblueprint.co.uk>
Thank you Matt very much for the code review! Pls. see comments inline.
On 5/27/2015 5:31 AM, Matt Fleming wrote:
> On Mon, 04 May, at 02:02:14PM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>>
>> Both x86 and ia64 implemented efi_mem_attributs function, which is architecture
>> agnositc. This function is moved to efi subsystem.
>>
>> efi_remap() function is added. If EFI memmap feature is enabled, and if a
>> memory region has attribute of EFI_MEMORY_UC, map it as uncached.
>>
>> ---
>> This patch was tested on an arm64 platform. It was built on x86 platform.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> ---
>> arch/ia64/kernel/efi.c | 11 -----------
>> arch/x86/platform/efi/efi.c | 18 ------------------
>> drivers/firmware/efi/efi.c | 27 +++++++++++++++++++++++++++
>> include/linux/efi.h | 1 +
>> 4 files changed, 28 insertions(+), 29 deletions(-)
>>
>> <snipped>
>
> This should be split into two patches, one to remove the duplicate
> efi_mem_attributes() and the other to create the new efi_ioremap()
> function.
Makes sense, will do.
>
>> +void __iomem *efi_remap(phys_addr_t phys_addr, size_t size)
>> +{
>> + if (efi_enabled(EFI_MEMMAP) &&
>> + (efi_mem_attributes(phys_addr) & EFI_MEMORY_UC))
>> + return ioremap(phys_addr, size);
>> + else
>> + return ioremap_cache(phys_addr, size);
>> +}
>
> Note that on x86 we don't leave the EFI memmap mapped throughout
> runtime, it gets unmapped in efi_free_boot_services().
>
> Which means that the second patch in this series isn't going to work
> correctly if an error is reported after the kernel has finished booting.
>
> It looks like arm64 leaves the EFI memmap mapped at runtime, right?
>
Correct, only x86 unmaps EFI memmap since efi_free_boot_services() is
not implemented for other architectures, as shown in include/linux/efi.h .
With x86 arch, efi_unmap_memmap() is called in efi_free_boot_services()
to unmap EFI memmap, this function is defined in
arch/x86/platform/efi/efi.c. It clears EFI_MEMMAP bit in efi flag.
Therefore in this case, efi_enabled(EFI_MEMMAP) returns false for x86
platforms with EFI memory map support, after kernel finished booting;
efi_remap() function in turn maps the memory region as cached.
Therefore, I believe the second patch in this series will work correctly
for above situation as well. How do you think?
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-05-27 19:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 21:02 [PATCH 0/2] map GHES memory region with EFI memory map Jonathan (Zhixiong) Zhang
2015-05-04 21:02 ` [PATCH 1/2] efi: arch, x86: arch, ia64: rearrange EFI memmap related functions Jonathan (Zhixiong) Zhang
2015-05-27 12:31 ` Matt Fleming
2015-05-27 19:35 ` Zhang, Jonathan Zhixiong [this message]
2015-05-04 21:02 ` [PATCH 2/2] acpi, apei: use EFI memmap to map GHES memory Jonathan (Zhixiong) Zhang
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=55661C95.5010200@codeaurora.org \
--to=zjzhang@codeaurora.org \
--cc=hpa@zytor.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox