From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/10] arm64/efi: reserve regions of type ACPI_MEMORY_NVS
Date: Wed, 22 Oct 2014 17:15:52 +0100 [thread overview]
Message-ID: <20141022161552.GG4010@leverpostej> (raw)
In-Reply-To: <1413987713-30528-5-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Oct 22, 2014 at 03:21:47PM +0100, Ard Biesheuvel wrote:
> Memory regions of type ACPI_MEMORY_NVS should be preserved
> by the OS, so make sure we reserve them at boot.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/efi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 95c49ebc660d..71ea4fc0aa8a 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -132,6 +132,7 @@ static __init int is_reserve_region(efi_memory_desc_t *md)
> return 1;
>
> if (md->type == EFI_ACPI_RECLAIM_MEMORY ||
> + md->type == EFI_ACPI_MEMORY_NVS ||
> md->type == EFI_RESERVED_TYPE)
> return 1;
Shouldn't we also filter out EFI_UNUSABLE_MEMORY? Or does that happen
elsewhere?
Perhaps instead we should invert this logic and assume memory should be
reserved if not EfiLoaderCode, EfiLoaderData, EfiBootServicesCode,
EfiBootServicesData, or EfiConventionalMemory. That looks to be what x86
does.
Mark.
next prev parent reply other threads:[~2014-10-22 16:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 14:21 [PATCH 00/10] arm64 EFI patches for 3.19 Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 01/10] arm64/efi: efistub: jump to 'stext' directly, not through the header Ard Biesheuvel
2014-10-22 14:47 ` Mark Rutland
2014-10-22 14:21 ` [PATCH 02/10] arm64/efi: set PE/COFF section alignment to 4 KB Ard Biesheuvel
2014-10-22 14:49 ` Mark Rutland
2014-10-22 14:21 ` [PATCH 03/10] arm64/efi: set PE/COFF file alignment to 512 bytes Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 04/10] arm64/efi: reserve regions of type ACPI_MEMORY_NVS Ard Biesheuvel
2014-10-22 16:15 ` Mark Rutland [this message]
2014-10-22 16:33 ` Ard Biesheuvel
2014-10-28 10:17 ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 05/10] arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES) Ard Biesheuvel
2014-10-27 12:22 ` Will Deacon
2014-10-22 14:21 ` [PATCH 06/10] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel
2014-10-22 17:06 ` Mark Salter
2014-10-22 17:20 ` Ard Biesheuvel
2014-10-22 17:29 ` Mark Salter
2014-10-23 15:54 ` Mark Rutland
2014-10-23 16:19 ` Mark Salter
2014-10-23 18:41 ` Ard Biesheuvel
2014-10-23 19:14 ` Mark Rutland
2014-10-23 19:23 ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 07/10] efi: dmi: add support for SMBIOS 3.0 UEFI configuration table Ard Biesheuvel
2014-10-27 15:26 ` Matt Fleming
2014-10-27 15:33 ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 08/10] dmi: add support for SMBIOS 3.0 64-bit entry point Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 09/10] arm64: dmi: Add SMBIOS/DMI support Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 10/10] arm64: dmi: set DMI string as dump stack arch description Ard Biesheuvel
2014-10-27 12:24 ` Will Deacon
2014-10-27 12:57 ` Ard Biesheuvel
2014-10-27 11:50 ` [PATCH 00/10] arm64 EFI patches for 3.19 Will Deacon
2014-10-27 12:03 ` Ard Biesheuvel
2014-10-27 17:45 ` Matt Fleming
2014-10-28 12:38 ` Will Deacon
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=20141022161552.GG4010@leverpostej \
--to=mark.rutland@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).