From: "Zhang, Jonathan Zhixiong" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-acpi-cunTk1MwBs8s++Sfvej+rw@public.gmane.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-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
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-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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
WARNING: multiple messages have this Message-ID (diff)
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: 8+ 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
[not found] ` <1430773335-22897-1-git-send-email-zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-05-04 21:02 ` [PATCH 1/2] efi: arch, x86: arch, ia64: rearrange EFI memmap related functions Jonathan (Zhixiong) Zhang
2015-05-04 21:02 ` Jonathan (Zhixiong) Zhang
[not found] ` <1430773335-22897-2-git-send-email-zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-05-27 12:31 ` Matt Fleming
2015-05-27 12:31 ` Matt Fleming
[not found] ` <20150527123103.GC3030-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-05-27 19:35 ` Zhang, Jonathan Zhixiong [this message]
2015-05-27 19:35 ` Zhang, Jonathan Zhixiong
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-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=linaro-acpi-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.