linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] arm64/efi: memblock_remove rather than _reserve UEFI reserved RAM
Date: Mon, 22 Dec 2014 19:08:42 +0000	[thread overview]
Message-ID: <1419275322-29811-9-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1419275322-29811-1-git-send-email-ard.biesheuvel@linaro.org>

Now that we have the 'physmem' memblock table to keep track of physical
RAM regions, we can start using memblock_remove() to eliminate UEFI
reserved regions from the 'memory' memblock table and the kernel direct
linear mapping entirely. This makes these regions inaccessible entirely,
unless they are remapped explicitly by the UEFI Runtime Services layer,
UEFI configuration table drivers or the ACPI layer.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/kernel/efi.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index b1b816ecf3b3..d0efd9df6216 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -167,7 +167,7 @@ static __init void reserve_regions(void)
 		if (uefi_debug) {
 			char buf[64];
 
-			pr_info("  0x%012llx-0x%012llx %s",
+			pr_info("  0x%012llx-0x%012llx %s\n",
 				paddr, paddr + (npages << EFI_PAGE_SHIFT) - 1,
 				efi_md_typeattr_format(buf, sizeof(buf), md));
 		}
@@ -177,15 +177,6 @@ static __init void reserve_regions(void)
 
 		if (is_normal_ram(md))
 			early_init_dt_add_memory_arch(paddr, size);
-
-		if (is_reserve_region(md)) {
-			memblock_reserve(paddr, size);
-			if (uefi_debug)
-				pr_cont("*");
-		}
-
-		if (uefi_debug)
-			pr_cont("\n");
 	}
 
 	/*
@@ -196,7 +187,18 @@ static __init void reserve_regions(void)
 	for_each_memblock(memory, r)
 		memblock_add_phys(r->base, r->size);
 
+	for_each_efi_memory_desc(&memmap, md) {
+		if (is_reserve_region(md)) {
+			paddr = md->phys_addr;
+			npages = md->num_pages;
+			memrange_efi_to_native(&paddr, &npages);
+			memblock_remove(paddr, npages << PAGE_SHIFT);
+		}
+	}
+
 	set_bit(EFI_MEMMAP, &efi.flags);
+	if (uefi_debug)
+		__memblock_dump_all();
 }
 
 void __init efi_init(void)
-- 
1.8.3.2

  parent reply	other threads:[~2014-12-22 19:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 19:08 [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 1/8] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel
2015-01-06  9:04   ` Matt Fleming
2015-01-07 11:48     ` Ard Biesheuvel
2015-01-12 10:46       ` Matt Fleming
2015-01-09 15:41   ` Will Deacon
2014-12-22 19:08 ` [PATCH 2/8] arm64/efi: register UEFI reserved regions as iomem resources Ard Biesheuvel
2015-01-06  9:13   ` Matt Fleming
2015-01-07 11:53     ` Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 3/8] memblock: add physmem to memblock_dump_all() output Ard Biesheuvel
2015-01-06  9:15   ` Matt Fleming
2014-12-22 19:08 ` [PATCH 4/8] memblock: introduce memblock_add_phys() and memblock_is_physmem() Ard Biesheuvel
2015-01-06  9:19   ` Matt Fleming
2014-12-22 19:08 ` [PATCH 5/8] of: fdt: register physmem in early_init_dt_scan_memory() Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 6/8] arm64/efi: register physmem in reserve_regions() Ard Biesheuvel
2014-12-22 19:08 ` [PATCH 7/8] arm64: use 'physmem' memblock to improve CONFIG_STRICT_DEVMEM handling Ard Biesheuvel
2015-01-09 15:38   ` Will Deacon
2014-12-22 19:08 ` Ard Biesheuvel [this message]
2014-12-26  9:35 ` [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc Dave Young
2014-12-29  9:22   ` Ard Biesheuvel
2014-12-30  9:25     ` Dave Young
2014-12-30 13:21       ` Ard Biesheuvel
2015-01-04  8:19         ` Dave Young
2015-01-05  9:18           ` Ard Biesheuvel
2015-01-06  8:16             ` Dave Young
2015-01-07 11:41               ` Ard Biesheuvel
2015-01-08  1:29                 ` Dave Young

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=1419275322-29811-9-git-send-email-ard.biesheuvel@linaro.org \
    --to=ard.biesheuvel@linaro.org \
    --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).