From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 7/7] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Mon, 16 Nov 2015 12:23:18 +0100 [thread overview]
Message-ID: <1447672998-20981-8-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1447672998-20981-1-git-send-email-ard.biesheuvel@linaro.org>
This relaxes the kernel Image placement requirements, so that it
may be placed at any 2 MB aligned offset in physical memory.
This is accomplished by ignoring PHYS_OFFSET when installing
memblocks, and accounting for the apparent virtual offset of
the kernel Image (in addition to the 64 MB that it is moved
below PAGE_OFFSET). As a result, virtual address references
below PAGE_OFFSET are correctly mapped onto physical references
into the kernel Image regardless of where it sits in memory.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Documentation/arm64/booting.txt | 12 ++---
arch/arm64/include/asm/memory.h | 9 ++--
arch/arm64/mm/init.c | 49 +++++++++++++++++++-
arch/arm64/mm/mmu.c | 29 ++++++++++--
4 files changed, 83 insertions(+), 16 deletions(-)
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 701d39d3171a..f190e708bb9b 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -117,14 +117,14 @@ Header notes:
depending on selected features, and is effectively unbound.
The Image must be placed text_offset bytes from a 2MB aligned base
-address near the start of usable system RAM and called there. Memory
-below that base address is currently unusable by Linux, and therefore it
-is strongly recommended that this location is the start of system RAM.
-The region between the 2 MB aligned base address and the start of the
-image has no special significance to the kernel, and may be used for
-other purposes.
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
At least image_size bytes from the start of the image must be free for
use by the kernel.
+NOTE: versions prior to v4.5 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
Any memory described to the kernel (even that below the start of the
image) which is not marked as reserved from the kernel (e.g., with a
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 3148691bc80a..d6a237bda1f9 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -120,13 +120,10 @@ extern phys_addr_t memstart_addr;
extern u64 kernel_va_offset;
/*
- * The maximum physical address that the linear direct mapping
- * of system RAM can cover. (PAGE_OFFSET can be interpreted as
- * a 2's complement signed quantity and negated to derive the
- * maximum size of the linear mapping.)
+ * Allow all memory at the discovery stage. We will clip it later.
*/
-#define MAX_MEMBLOCK_ADDR ({ memstart_addr - PAGE_OFFSET - 1; })
-#define MIN_MEMBLOCK_ADDR __pa(KIMAGE_VADDR)
+#define MIN_MEMBLOCK_ADDR 0
+#define MAX_MEMBLOCK_ADDR U64_MAX
/*
* PFNs are used to describe any physical page; this means
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index b3b0175d7135..29a7dc5327b6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -35,6 +35,7 @@
#include <linux/efi.h>
#include <linux/swiotlb.h>
+#include <asm/boot.h>
#include <asm/fixmap.h>
#include <asm/kernel-pgtable.h>
#include <asm/memory.h>
@@ -158,9 +159,55 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
+static void __init enforce_memory_limit(void)
+{
+ const phys_addr_t kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
+ u64 to_remove = memblock_phys_mem_size() - memory_limit;
+ phys_addr_t max_addr = 0;
+ struct memblock_region *r;
+
+ if (memory_limit == (phys_addr_t)ULLONG_MAX)
+ return;
+
+ /*
+ * The kernel may be high up in physical memory, so try to apply the
+ * limit below the kernel first, and only let the generic handling
+ * take over if it turns out we haven't clipped enough memory yet.
+ */
+ for_each_memblock(memory, r) {
+ if (r->base + r->size > kbase) {
+ u64 rem = min(to_remove, kbase - r->base);
+
+ max_addr = r->base + rem;
+ to_remove -= rem;
+ break;
+ }
+ if (to_remove <= r->size) {
+ max_addr = r->base + to_remove;
+ to_remove = 0;
+ break;
+ }
+ to_remove -= r->size;
+ }
+
+ memblock_remove(0, max_addr);
+
+ if (to_remove)
+ memblock_enforce_memory_limit(memory_limit);
+}
+
void __init arm64_memblock_init(void)
{
- memblock_enforce_memory_limit(memory_limit);
+ /*
+ * Remove the memory that we will not be able to cover
+ * with the linear mapping.
+ */
+ const s64 linear_region_size = -(s64)PAGE_OFFSET;
+
+ memblock_remove(round_down(memblock_start_of_DRAM(), SZ_1G) +
+ linear_region_size, ULLONG_MAX);
+
+ enforce_memory_limit();
/*
* Register the kernel text, kernel data, initrd, and initial
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 526eeb7e1e97..1b9d7e48ba1e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -21,6 +21,7 @@
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/init.h>
+#include <linux/initrd.h>
#include <linux/libfdt.h>
#include <linux/mman.h>
#include <linux/nodemask.h>
@@ -481,11 +482,33 @@ static void __init bootstrap_linear_mapping(unsigned long va_offset)
static void __init map_mem(void)
{
struct memblock_region *reg;
+ u64 new_memstart_addr;
+ u64 new_va_offset;
- bootstrap_linear_mapping(KIMAGE_OFFSET);
+ /*
+ * Select a suitable value for the base of physical memory.
+ * This should be equal to or below the lowest usable physical
+ * memory address, and aligned to PUD/PMD size so that we can map
+ * it efficiently.
+ */
+ new_memstart_addr = round_down(memblock_start_of_DRAM(), SZ_1G);
+
+ /*
+ * Calculate the offset between the kernel text mapping that exists
+ * outside of the linear mapping, and its mapping in the linear region.
+ */
+ new_va_offset = memstart_addr - new_memstart_addr;
+
+ bootstrap_linear_mapping(new_va_offset);
- kernel_va_offset = KIMAGE_OFFSET;
- memstart_addr -= KIMAGE_OFFSET;
+ kernel_va_offset = new_va_offset;
+ memstart_addr = new_memstart_addr;
+
+ /* Recalculate virtual addresses of initrd region */
+ if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
+ initrd_start += new_va_offset;
+ initrd_end += new_va_offset;
+ }
/* map all the memory banks */
for_each_memblock(memory, reg) {
--
1.9.1
next prev parent reply other threads:[~2015-11-16 11:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 11:23 [PATCH v3 0/7] arm64: relax Image placement rules Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 1/7] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 2/7] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 3/7] arm64: split off early mapping code from early_fixmap_init() Ard Biesheuvel
2015-12-03 12:18 ` Mark Rutland
2015-12-03 13:31 ` Ard Biesheuvel
2015-12-03 13:59 ` Mark Rutland
2015-12-03 14:05 ` Ard Biesheuvel
2015-12-07 16:08 ` Catalin Marinas
2015-12-07 16:13 ` Ard Biesheuvel
2015-12-08 12:40 ` Will Deacon
2015-12-08 13:29 ` Ard Biesheuvel
2015-12-08 13:51 ` Will Deacon
2015-12-15 19:19 ` Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 4/7] arm64: mm: explicitly bootstrap the linear mapping Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 5/7] arm64: move kernel mapping out of linear region Ard Biesheuvel
2015-12-07 12:26 ` Catalin Marinas
2015-12-07 12:33 ` Ard Biesheuvel
2015-12-07 12:34 ` Ard Biesheuvel
2015-12-07 15:37 ` Catalin Marinas
2015-11-16 11:23 ` [PATCH v3 6/7] arm64: map linear region as non-executable Ard Biesheuvel
2015-12-07 16:19 ` Catalin Marinas
2015-12-07 16:22 ` Ard Biesheuvel
2015-12-07 16:27 ` Catalin Marinas
2015-11-16 11:23 ` Ard Biesheuvel [this message]
2015-12-07 15:30 ` [PATCH v3 7/7] arm64: allow kernel Image to be loaded anywhere in physical memory Catalin Marinas
2015-12-07 15:40 ` Ard Biesheuvel
2015-12-07 16:43 ` Catalin Marinas
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=1447672998-20981-8-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).