From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot
Date: Wed, 4 Jul 2018 18:06:55 +0100 [thread overview]
Message-ID: <20180704170655.GD8370@arm.com> (raw)
In-Reply-To: <20180619064424.6642-4-takahiro.akashi@linaro.org>
Hi all,
[Ard -- please can you look at the EFI parts of this patch]
On Tue, Jun 19, 2018 at 03:44:23PM +0900, AKASHI Takahiro wrote:
> Since arm_enter_runtime_services() was modified to always create a virtual
> mapping of UEFI memory map in the previous patch, it is now renamed to
> efi_enter_virtual_mode() and called earlier before acpi_load_tables()
> in acpi_early_init().
>
> This will allow us to use UEFI memory map in acpi_os_ioremap() to create
> mappings of ACPI tables using memory attributes described in UEFI memory
> map.
>
> See a relevant commit:
> arm64: acpi: fix alignment fault in accessing ACPI tables
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> drivers/firmware/efi/arm-runtime.c | 15 ++++++---------
> init/main.c | 3 +++
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 30ac5c82051e..566ef0a9edb5 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void)
> * non-early mapping of the UEFI system table and virtual mappings for all
> * EFI_MEMORY_RUNTIME regions.
> */
> -static int __init arm_enable_runtime_services(void)
> +void __init efi_enter_virtual_mode(void)
> {
> u64 mapsize;
>
> if (!efi_enabled(EFI_BOOT)) {
> pr_info("EFI services will not be available.\n");
> - return 0;
> + return;
> }
>
> mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
>
> if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> pr_err("Failed to remap EFI memory map\n");
> - return 0;
> + return;
> }
>
> if (efi_runtime_disabled()) {
> pr_info("EFI runtime services will be disabled.\n");
> - return 0;
> + return;
> }
>
> if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> pr_info("EFI runtime services access via paravirt.\n");
> - return 0;
> + return;
> }
>
> pr_info("Remapping and enabling EFI services.\n");
>
> if (!efi_virtmap_init()) {
> pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
> - return -ENOMEM;
> + return;
> }
>
> /* Set up runtime services function pointers */
> efi_native_runtime_setup();
> set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
> -
> - return 0;
> }
> -early_initcall(arm_enable_runtime_services);
>
> void efi_virtmap_load(void)
> {
> diff --git a/init/main.c b/init/main.c
> index 3b4ada11ed52..532fc0d02353 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -694,6 +694,9 @@ asmlinkage __visible void __init start_kernel(void)
> debug_objects_mem_init();
> setup_per_cpu_pageset();
> numa_policy_init();
> + if (IS_ENABLED(CONFIG_EFI) &&
> + (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)))
> + efi_enter_virtual_mode();
Hmm, this is ugly as hell. Is there nothing else we can piggy-back off?
It's also fairly jarring that, on x86, efi_enter_virtual_mode() is called
a few lines later, *after* acpi_early_init() has been called.
The rest of the series looks fine to me, but I'm not comfortable taking
changes like this via the arm64 tree.
Will
next prev parent reply other threads:[~2018-07-04 17:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 6:44 [PATCH v2 0/4] arm64: kexec, kdump: fix boot failures on acpi-only system AKASHI Takahiro
2018-06-19 6:44 ` [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem AKASHI Takahiro
2018-06-19 13:37 ` Dave Kleikamp
2018-06-19 15:00 ` James Morse
2018-06-19 15:22 ` Dave Kleikamp
2018-07-03 6:47 ` AKASHI Takahiro
2018-07-03 12:14 ` Bhupesh Sharma
2018-07-03 16:12 ` Dave Kleikamp
2018-07-05 22:29 ` Ard Biesheuvel
2018-06-19 6:44 ` [PATCH v2 2/4] efi/arm: map UEFI memory map even w/o runtime services enabled AKASHI Takahiro
2018-06-28 17:29 ` James Morse
2018-07-05 22:26 ` Ard Biesheuvel
2018-06-19 6:44 ` [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot AKASHI Takahiro
2018-07-04 17:06 ` Will Deacon [this message]
2018-07-04 18:49 ` Ard Biesheuvel
2018-07-05 9:43 ` AKASHI Takahiro
2018-07-05 11:02 ` James Morse
2018-07-05 16:48 ` Will Deacon
2018-07-05 22:31 ` Ard Biesheuvel
2018-07-06 0:42 ` AKASHI Takahiro
2018-07-06 1:33 ` AKASHI Takahiro
2018-07-06 13:37 ` Will Deacon
2018-06-19 6:44 ` [PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI AKASHI Takahiro
2018-06-28 17:28 ` James Morse
2018-07-05 22:27 ` Ard Biesheuvel
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=20180704170655.GD8370@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).