2019-06-04 01:11:33 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* linux/arch/arm/mm/mmu.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1995-2005 Russell King
|
|
|
|
*/
|
2006-09-27 07:38:34 -07:00
|
|
|
#include <linux/module.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/nodemask.h>
|
2010-07-09 08:27:52 -07:00
|
|
|
#include <linux/memblock.h>
|
2010-09-13 08:01:24 -07:00
|
|
|
#include <linux/fs.h>
|
2011-08-24 21:35:59 -07:00
|
|
|
#include <linux/vmalloc.h>
|
2012-06-24 04:46:26 -07:00
|
|
|
#include <linux/sizes.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
|
2012-03-28 10:30:01 -07:00
|
|
|
#include <asm/cp15.h>
|
2008-08-10 10:08:10 -07:00
|
|
|
#include <asm/cputype.h>
|
2008-11-03 22:48:42 -07:00
|
|
|
#include <asm/cachetype.h>
|
2013-10-24 00:12:39 -07:00
|
|
|
#include <asm/sections.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
#include <asm/setup.h>
|
2009-09-27 12:55:43 -07:00
|
|
|
#include <asm/smp_plat.h>
|
2023-06-02 11:28:43 -07:00
|
|
|
#include <asm/tcm.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
#include <asm/tlb.h>
|
2008-09-15 13:44:55 -07:00
|
|
|
#include <asm/highmem.h>
|
2012-03-28 10:30:01 -07:00
|
|
|
#include <asm/system_info.h>
|
2010-09-13 08:03:21 -07:00
|
|
|
#include <asm/traps.h>
|
2013-07-31 09:44:46 -07:00
|
|
|
#include <asm/procinfo.h>
|
ARM: mm: Make virt_to_pfn() a static inline
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
Doing this is a bit intrusive: virt_to_pfn() requires
PHYS_PFN_OFFSET and PAGE_SHIFT to be defined, and this is defined in
<asm/page.h>, so this must be included *before* <asm/memory.h>.
The use of macros were obscuring the unclear inclusion order here,
as the macros would eventually be resolved, but a static inline
like this cannot be compiled with unresolved macros.
The naive solution to include <asm/page.h> at the top of
<asm/memory.h> does not work, because <asm/memory.h> sometimes
includes <asm/page.h> at the end of itself, which would create a
confusing inclusion loop. So instead, take the approach to always
unconditionally include <asm/page.h> at the end of <asm/memory.h>
arch/arm uses <asm/memory.h> explicitly in a lot of places,
however it turns out that if we just unconditionally include
<asm/memory.h> into <asm/page.h> and switch all inclusions of
<asm/memory.h> to <asm/page.h> instead, we enforce the right
order and <asm/memory.h> will always have access to the
definitions.
Put an inclusion guard in place making it impossible to include
<asm/memory.h> explicitly.
Link: https://lore.kernel.org/linux-mm/20220701160004.2ffff4e5ab59a55499f4c736@linux-foundation.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-06-02 01:18:32 -07:00
|
|
|
#include <asm/page.h>
|
2020-08-06 23:22:28 -07:00
|
|
|
#include <asm/pgalloc.h>
|
ARM: 9015/2: Define the virtual space of KASan's shadow region
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
addressable by a 32bit architecture) out of the virtual address
space to use as shadow memory for KASan as follows:
+----+ 0xffffffff
| |
| | |-> Static kernel image (vmlinux) BSS and page table
| |/
+----+ PAGE_OFFSET
| |
| | |-> Loadable kernel modules virtual address space area
| |/
+----+ MODULES_VADDR = KASAN_SHADOW_END
| |
| | |-> The shadow area of kernel virtual address.
| |/
+----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
| | shadow address of MODULES_VADDR
| | |
| | |
| | |-> The user space area in lowmem. The kernel address
| | | sanitizer do not use this space, nor does it map it.
| | |
| | |
| | |
| | |
| |/
------ 0
0 .. TASK_SIZE is the memory that can be used by shared
userspace/kernelspace. It us used for userspace processes and for
passing parameters and memory buffers in system calls etc. We do not
need to shadow this area.
KASAN_SHADOW_START:
This value begins with the MODULE_VADDR's shadow address. It is the
start of kernel virtual space. Since we have modules to load, we need
to cover also that area with shadow memory so we can find memory
bugs in modules.
KASAN_SHADOW_END
This value is the 0x100000000's shadow address: the mapping that would
be after the end of the kernel memory at 0xffffffff. It is the end of
kernel address sanitizer shadow area. It is also the start of the
module area.
KASAN_SHADOW_OFFSET:
This value is used to map an address to the corresponding shadow
address by the following formula:
shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
As you would expect, >> 3 is equal to dividing by 8, meaning each
byte in the shadow memory covers 8 bytes of kernel memory, so one
bit shadow memory per byte of kernel memory is used.
The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
on the VMSPLIT layout of the system: the kernel and userspace can
split up lowmem in different ways according to needs, so we calculate
the shadow offset depending on this.
When kasan is enabled, the definition of TASK_SIZE is not an 8-bit
rotated constant, so we need to modify the TASK_SIZE access code in the
*.s file.
The kernel and modules may use different amounts of memory,
according to the VMSPLIT configuration, which in turn
determines the PAGE_OFFSET.
We use the following KASAN_SHADOW_OFFSETs depending on how the
virtual memory is split up:
- 0x1f000000 if we have 1G userspace / 3G kernelspace split:
- The kernel address space is 3G (0xc0000000)
- PAGE_OFFSET is then set to 0x40000000 so the kernel static
image (vmlinux) uses addresses 0x40000000 .. 0xffffffff
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x3f000000
so the modules use addresses 0x3f000000 .. 0x3fffffff
- So the addresses 0x3f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0xc1000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x18200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x26e00000, to
KASAN_SHADOW_END at 0x3effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x3f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000
KASAN_SHADOW_OFFSET = 0x1f000000
- 0x5f000000 if we have 2G userspace / 2G kernelspace split:
- The kernel space is 2G (0x80000000)
- PAGE_OFFSET is set to 0x80000000 so the kernel static
image uses 0x80000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x7f000000
so the modules use addresses 0x7f000000 .. 0x7fffffff
- So the addresses 0x7f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x81000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x10200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x6ee00000, to
KASAN_SHADOW_END at 0x7effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x7f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000
KASAN_SHADOW_OFFSET = 0x5f000000
- 0x9f000000 if we have 3G userspace / 1G kernelspace split,
and this is the default split for ARM:
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xc0000000 so the kernel static
image uses 0xc0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xbf000000
so the modules use addresses 0xbf000000 .. 0xbfffffff
- So the addresses 0xbf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x41000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x08200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xb6e00000, to
KASAN_SHADOW_END at 0xbfffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xbf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000
KASAN_SHADOW_OFFSET = 0x9f000000
- 0x8f000000 if we have 3G userspace / 1G kernelspace with
full 1 GB low memory (VMSPLIT_3G_OPT):
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xb0000000 so the kernel static
image uses 0xb0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xaf000000
so the modules use addresses 0xaf000000 .. 0xaffffff
- So the addresses 0xaf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x51000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x0a200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xa4e00000, to
KASAN_SHADOW_END at 0xaeffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xaf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000
KASAN_SHADOW_OFFSET = 0x8f000000
- The default value of 0xffffffff for KASAN_SHADOW_OFFSET
is an error value. We should always match one of the
above shadow offsets.
When we do this, TASK_SIZE will sometimes get a bit odd values
that will not fit into immediate mov assembly instructions.
To account for this, we need to rewrite some assembly using
TASK_SIZE like this:
- mov r1, #TASK_SIZE
+ ldr r1, =TASK_SIZE
or
- cmp r4, #TASK_SIZE
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
this is done to avoid the immediate #TASK_SIZE that need to
fit into a limited number of bits.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-25 15:53:46 -07:00
|
|
|
#include <asm/kasan_def.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
#include <asm/mach/arch.h>
|
|
|
|
#include <asm/mach/map.h>
|
2012-02-29 17:10:58 -07:00
|
|
|
#include <asm/mach/pci.h>
|
2014-04-18 01:43:32 -07:00
|
|
|
#include <asm/fixmap.h>
|
2006-09-27 07:27:33 -07:00
|
|
|
|
2015-10-19 05:38:09 -07:00
|
|
|
#include "fault.h"
|
2006-09-27 07:27:33 -07:00
|
|
|
#include "mm.h"
|
|
|
|
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
extern unsigned long __atags_pointer;
|
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* empty_zero_page is a special page that is used for
|
|
|
|
* zero-initialized data and COW.
|
|
|
|
*/
|
|
|
|
struct page *empty_zero_page;
|
2008-04-29 05:11:12 -07:00
|
|
|
EXPORT_SYMBOL(empty_zero_page);
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The pmd table for the upper-most set of pages.
|
|
|
|
*/
|
|
|
|
pmd_t *top_pmd;
|
|
|
|
|
2014-11-28 18:33:30 -07:00
|
|
|
pmdval_t user_pmd_table = _PAGE_USER_TABLE;
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
#define CPOLICY_UNCACHED 0
|
|
|
|
#define CPOLICY_BUFFERED 1
|
|
|
|
#define CPOLICY_WRITETHROUGH 2
|
|
|
|
#define CPOLICY_WRITEBACK 3
|
|
|
|
#define CPOLICY_WRITEALLOC 4
|
|
|
|
|
|
|
|
static unsigned int cachepolicy __initdata = CPOLICY_WRITEBACK;
|
|
|
|
static unsigned int ecc_mask __initdata = 0;
|
2007-02-11 05:45:13 -07:00
|
|
|
pgprot_t pgprot_user;
|
2006-09-27 07:38:34 -07:00
|
|
|
pgprot_t pgprot_kernel;
|
|
|
|
|
2007-02-11 05:45:13 -07:00
|
|
|
EXPORT_SYMBOL(pgprot_user);
|
2006-09-27 07:38:34 -07:00
|
|
|
EXPORT_SYMBOL(pgprot_kernel);
|
|
|
|
|
|
|
|
struct cachepolicy {
|
|
|
|
const char policy[16];
|
|
|
|
unsigned int cr_mask;
|
2011-09-05 09:51:56 -07:00
|
|
|
pmdval_t pmd;
|
2010-11-15 17:22:09 -07:00
|
|
|
pteval_t pte;
|
2006-09-27 07:38:34 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct cachepolicy cache_policies[] __initdata = {
|
|
|
|
{
|
|
|
|
.policy = "uncached",
|
|
|
|
.cr_mask = CR_W|CR_C,
|
|
|
|
.pmd = PMD_SECT_UNCACHED,
|
2008-09-06 12:04:59 -07:00
|
|
|
.pte = L_PTE_MT_UNCACHED,
|
2006-09-27 07:38:34 -07:00
|
|
|
}, {
|
|
|
|
.policy = "buffered",
|
|
|
|
.cr_mask = CR_C,
|
|
|
|
.pmd = PMD_SECT_BUFFERED,
|
2008-09-06 12:04:59 -07:00
|
|
|
.pte = L_PTE_MT_BUFFERABLE,
|
2006-09-27 07:38:34 -07:00
|
|
|
}, {
|
|
|
|
.policy = "writethrough",
|
|
|
|
.cr_mask = 0,
|
|
|
|
.pmd = PMD_SECT_WT,
|
2008-09-06 12:04:59 -07:00
|
|
|
.pte = L_PTE_MT_WRITETHROUGH,
|
2006-09-27 07:38:34 -07:00
|
|
|
}, {
|
|
|
|
.policy = "writeback",
|
|
|
|
.cr_mask = 0,
|
|
|
|
.pmd = PMD_SECT_WB,
|
2008-09-06 12:04:59 -07:00
|
|
|
.pte = L_PTE_MT_WRITEBACK,
|
2006-09-27 07:38:34 -07:00
|
|
|
}, {
|
|
|
|
.policy = "writealloc",
|
|
|
|
.cr_mask = 0,
|
|
|
|
.pmd = PMD_SECT_WBWA,
|
2008-09-06 12:04:59 -07:00
|
|
|
.pte = L_PTE_MT_WRITEALLOC,
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2012-01-16 02:34:31 -07:00
|
|
|
#ifdef CONFIG_CPU_CP15
|
2014-06-02 01:29:37 -07:00
|
|
|
static unsigned long initial_pmd_value __initdata = 0;
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
2014-05-27 12:34:28 -07:00
|
|
|
* Initialise the cache_policy variable with the initial state specified
|
|
|
|
* via the "pmd" value. This is used to ensure that on ARMv6 and later,
|
|
|
|
* the C code sets the page tables up with the same policy as the head
|
|
|
|
* assembly code, which avoids an illegal state where the TLBs can get
|
|
|
|
* confused. See comments in early_cachepolicy() for more information.
|
2006-09-27 07:38:34 -07:00
|
|
|
*/
|
2014-05-27 12:34:28 -07:00
|
|
|
void __init init_default_cache_policy(unsigned long pmd)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2014-06-02 01:29:37 -07:00
|
|
|
initial_pmd_value = pmd;
|
|
|
|
|
2016-09-07 13:56:09 -07:00
|
|
|
pmd &= PMD_SECT_CACHE_MASK;
|
2014-05-27 12:34:28 -07:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(cache_policies); i++)
|
|
|
|
if (cache_policies[i].pmd == pmd) {
|
|
|
|
cachepolicy = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == ARRAY_SIZE(cache_policies))
|
|
|
|
pr_err("ERROR: could not find cache policy\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These are useful for identifying cache coherency problems by allowing
|
|
|
|
* the cache or the cache and writebuffer to be turned off. (Note: the
|
|
|
|
* write buffer should not be on and the cache off).
|
|
|
|
*/
|
|
|
|
static int __init early_cachepolicy(char *p)
|
|
|
|
{
|
|
|
|
int i, selected = -1;
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
for (i = 0; i < ARRAY_SIZE(cache_policies); i++) {
|
|
|
|
int len = strlen(cache_policies[i].policy);
|
|
|
|
|
2010-01-11 15:17:34 -07:00
|
|
|
if (memcmp(p, cache_policies[i].policy, len) == 0) {
|
2014-05-27 12:34:28 -07:00
|
|
|
selected = i;
|
2006-09-27 07:38:34 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2014-05-27 12:34:28 -07:00
|
|
|
|
|
|
|
if (selected == -1)
|
|
|
|
pr_err("ERROR: unknown or unsupported cache policy\n");
|
|
|
|
|
2009-11-01 10:44:24 -07:00
|
|
|
/*
|
|
|
|
* This restriction is partly to do with the way we boot; it is
|
|
|
|
* unpredictable to have memory mapped using two different sets of
|
|
|
|
* memory attributes (shared, type, and cache attribs). We can not
|
|
|
|
* change these attributes once the initial assembly has setup the
|
|
|
|
* page tables.
|
|
|
|
*/
|
2014-05-27 12:34:28 -07:00
|
|
|
if (cpu_architecture() >= CPU_ARCH_ARMv6 && selected != cachepolicy) {
|
|
|
|
pr_warn("Only cachepolicy=%s supported on ARMv6 and later\n",
|
|
|
|
cache_policies[cachepolicy].policy);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (selected != cachepolicy) {
|
|
|
|
unsigned long cr = __clear_cr(cache_policies[selected].cr_mask);
|
|
|
|
cachepolicy = selected;
|
|
|
|
flush_cache_all();
|
|
|
|
set_cr(cr);
|
2007-07-20 03:42:24 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
return 0;
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
early_param("cachepolicy", early_cachepolicy);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2010-01-11 15:17:34 -07:00
|
|
|
static int __init early_nocache(char *__unused)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
|
|
|
char *p = "buffered";
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_warn("nocache is deprecated; use cachepolicy=%s\n", p);
|
2010-01-11 15:17:34 -07:00
|
|
|
early_cachepolicy(p);
|
|
|
|
return 0;
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
early_param("nocache", early_nocache);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2010-01-11 15:17:34 -07:00
|
|
|
static int __init early_nowrite(char *__unused)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
|
|
|
char *p = "uncached";
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_warn("nowb is deprecated; use cachepolicy=%s\n", p);
|
2010-01-11 15:17:34 -07:00
|
|
|
early_cachepolicy(p);
|
|
|
|
return 0;
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
early_param("nowb", early_nowrite);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2010-01-11 15:17:34 -07:00
|
|
|
static int __init early_ecc(char *p)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
2010-01-11 15:17:34 -07:00
|
|
|
if (memcmp(p, "on", 2) == 0)
|
2006-09-27 07:38:34 -07:00
|
|
|
ecc_mask = PMD_PROTECTION;
|
2010-01-11 15:17:34 -07:00
|
|
|
else if (memcmp(p, "off", 3) == 0)
|
2006-09-27 07:38:34 -07:00
|
|
|
ecc_mask = 0;
|
2010-01-11 15:17:34 -07:00
|
|
|
return 0;
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
early_param("ecc", early_ecc);
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2012-01-16 02:34:31 -07:00
|
|
|
#else /* ifdef CONFIG_CPU_CP15 */
|
|
|
|
|
|
|
|
static int __init early_cachepolicy(char *p)
|
|
|
|
{
|
2014-09-16 12:41:43 -07:00
|
|
|
pr_warn("cachepolicy kernel parameter not supported without cp15\n");
|
2022-02-23 12:46:35 -07:00
|
|
|
return 0;
|
2012-01-16 02:34:31 -07:00
|
|
|
}
|
|
|
|
early_param("cachepolicy", early_cachepolicy);
|
|
|
|
|
|
|
|
static int __init noalign_setup(char *__unused)
|
|
|
|
{
|
2014-09-16 12:41:43 -07:00
|
|
|
pr_warn("noalign kernel parameter not supported without cp15\n");
|
2022-02-23 12:46:35 -07:00
|
|
|
return 1;
|
2012-01-16 02:34:31 -07:00
|
|
|
}
|
|
|
|
__setup("noalign", noalign_setup);
|
|
|
|
|
|
|
|
#endif /* ifdef CONFIG_CPU_CP15 / else */
|
|
|
|
|
2010-11-16 01:40:36 -07:00
|
|
|
#define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
|
2014-02-02 14:21:31 -07:00
|
|
|
#define PROT_PTE_S2_DEVICE PROT_PTE_DEVICE
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
#define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
|
2007-05-05 12:28:16 -07:00
|
|
|
|
2016-08-10 14:46:49 -07:00
|
|
|
static struct mem_type mem_types[] __ro_after_init = {
|
2007-05-05 12:28:16 -07:00
|
|
|
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
|
2008-09-06 12:04:59 -07:00
|
|
|
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
|
|
|
|
L_PTE_SHARED,
|
2007-05-05 12:28:16 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
|
2007-05-05 12:28:16 -07:00
|
|
|
.domain = DOMAIN_IO,
|
|
|
|
},
|
|
|
|
[MT_DEVICE_NONSHARED] = { /* ARMv6 non-shared device */
|
2008-09-06 12:04:59 -07:00
|
|
|
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_NONSHARED,
|
2007-05-05 12:28:16 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
.prot_sect = PROT_SECT_DEVICE,
|
2007-05-05 12:28:16 -07:00
|
|
|
.domain = DOMAIN_IO,
|
|
|
|
},
|
2019-08-11 05:03:29 -07:00
|
|
|
[MT_DEVICE_CACHED] = { /* ioremap_cache */
|
2008-09-06 12:04:59 -07:00
|
|
|
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
|
2007-05-05 12:28:16 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_WB,
|
|
|
|
.domain = DOMAIN_IO,
|
2012-02-29 17:10:58 -07:00
|
|
|
},
|
[ARM] 5241/1: provide ioremap_wc()
This patch provides an ARM implementation of ioremap_wc().
We use different page table attributes depending on which CPU we
are running on:
- Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
possible mapping types (CB=00/01/10/11). We can't use any of the
cached memory types (CB=10/11), since that breaks coherency with
peripheral devices. Both CB=00 and CB=01 are suitable for _wc, and
CB=01 (Uncached/Buffered) allows the hardware more freedom than
CB=00, so we'll use that.
(The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
but isn't allowed to merge them, but there is no other mapping type
we can use that allows the hardware to delay and merge stores, so
we'll go with CB=01.)
- XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
difference that on these platforms, CB=01 actually _does_ allow
merging stores. (If you want noncoalescing bufferable behavior
on Xscale v1/v2, you need to use XCB=101.)
- Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
in ARMv6 parlance).
The ARMv6 ARM explicitly says that any accesses to Normal memory can
be merged, which makes Normal memory more suitable for _wc mappings
than Device or Strongly Ordered memory, as the latter two mapping
types are guaranteed to maintain transaction number, size and order.
We use the Uncached variety of Normal mappings for the same reason
that we can't use C=1 mappings on ARMv5.
The xsc3 Architecture Specification documents TEXCB=00100 as being
Uncacheable and allowing coalescing of writes, which is also just
what we need.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05 05:17:11 -07:00
|
|
|
[MT_DEVICE_WC] = { /* ioremap_wc */
|
2008-09-06 12:04:59 -07:00
|
|
|
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,
|
2007-05-05 12:28:16 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
.prot_sect = PROT_SECT_DEVICE,
|
2007-05-05 12:28:16 -07:00
|
|
|
.domain = DOMAIN_IO,
|
2006-09-27 07:38:34 -07:00
|
|
|
},
|
2008-11-09 04:18:36 -07:00
|
|
|
[MT_UNCACHED] = {
|
|
|
|
.prot_pte = PROT_PTE_DEVICE,
|
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
|
|
|
|
.domain = DOMAIN_IO,
|
|
|
|
},
|
2006-09-27 07:38:34 -07:00
|
|
|
[MT_CACHECLEAN] = {
|
2007-05-05 12:03:35 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
|
2006-09-27 07:38:34 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2006-09-27 07:38:34 -07:00
|
|
|
[MT_MINICLEAN] = {
|
2007-05-05 12:03:35 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN | PMD_SECT_MINICACHE,
|
2006-09-27 07:38:34 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2006-09-27 07:38:34 -07:00
|
|
|
[MT_LOW_VECTORS] = {
|
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
2010-11-16 01:40:36 -07:00
|
|
|
L_PTE_RDONLY,
|
2006-09-27 07:38:34 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
2015-08-21 01:38:31 -07:00
|
|
|
.domain = DOMAIN_VECTORS,
|
2006-09-27 07:38:34 -07:00
|
|
|
},
|
|
|
|
[MT_HIGH_VECTORS] = {
|
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
2010-11-16 01:40:36 -07:00
|
|
|
L_PTE_USER | L_PTE_RDONLY,
|
2006-09-27 07:38:34 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
2015-08-21 01:38:31 -07:00
|
|
|
.domain = DOMAIN_VECTORS,
|
2006-09-27 07:38:34 -07:00
|
|
|
},
|
2013-10-24 02:26:40 -07:00
|
|
|
[MT_MEMORY_RWX] = {
|
2010-11-16 01:40:36 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY,
|
2010-09-23 23:18:22 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
2007-05-05 12:03:35 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
|
2006-09-27 07:38:34 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2013-10-24 00:12:39 -07:00
|
|
|
[MT_MEMORY_RW] = {
|
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
|
|
|
L_PTE_XN,
|
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
|
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
[MT_MEMORY_RO] = {
|
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
|
|
|
L_PTE_XN | L_PTE_RDONLY,
|
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
2022-09-16 04:10:49 -07:00
|
|
|
#ifdef CONFIG_ARM_LPAE
|
|
|
|
.prot_sect = PMD_TYPE_SECT | L_PMD_SECT_RDONLY | PMD_SECT_AP2,
|
|
|
|
#else
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT,
|
2022-09-16 04:10:49 -07:00
|
|
|
#endif
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2006-09-27 07:38:34 -07:00
|
|
|
[MT_ROM] = {
|
2007-05-05 12:03:35 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT,
|
2006-09-27 07:38:34 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2013-10-24 02:26:40 -07:00
|
|
|
[MT_MEMORY_RWX_NONCACHED] = {
|
2010-09-23 23:18:22 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
2010-11-16 01:40:36 -07:00
|
|
|
L_PTE_MT_BUFFERABLE,
|
2010-09-23 23:18:22 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.
On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."
If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.
TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:
http://www.spinics.net/lists/arm-kernel/msg54312.html
This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 12:11:43 -07:00
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
|
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2013-10-24 02:26:40 -07:00
|
|
|
[MT_MEMORY_RW_DTCM] = {
|
2010-10-18 01:03:03 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
2010-11-16 01:40:36 -07:00
|
|
|
L_PTE_XN,
|
2010-10-18 01:03:03 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
|
|
|
|
.domain = DOMAIN_KERNEL,
|
2010-07-12 13:50:59 -07:00
|
|
|
},
|
2013-10-24 02:26:40 -07:00
|
|
|
[MT_MEMORY_RWX_ITCM] = {
|
2010-11-16 01:40:36 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY,
|
2010-07-12 13:50:59 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
2010-10-18 01:03:03 -07:00
|
|
|
.domain = DOMAIN_KERNEL,
|
2010-07-12 13:50:59 -07:00
|
|
|
},
|
2013-10-24 02:26:40 -07:00
|
|
|
[MT_MEMORY_RW_SO] = {
|
2011-06-28 12:42:56 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
2013-01-16 23:18:04 -07:00
|
|
|
L_PTE_MT_UNCACHED | L_PTE_XN,
|
2011-06-28 12:42:56 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_S |
|
|
|
|
PMD_SECT_UNCACHED | PMD_SECT_XN,
|
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2011-12-29 05:09:51 -07:00
|
|
|
[MT_MEMORY_DMA_READY] = {
|
2013-11-25 05:01:03 -07:00
|
|
|
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
|
|
|
|
L_PTE_XN,
|
2011-12-29 05:09:51 -07:00
|
|
|
.prot_l1 = PMD_TYPE_TABLE,
|
|
|
|
.domain = DOMAIN_KERNEL,
|
|
|
|
},
|
2006-09-27 07:38:34 -07:00
|
|
|
};
|
|
|
|
|
2007-04-21 02:47:29 -07:00
|
|
|
const struct mem_type *get_mem_type(unsigned int type)
|
|
|
|
{
|
|
|
|
return type < ARRAY_SIZE(mem_types) ? &mem_types[type] : NULL;
|
|
|
|
}
|
2009-01-28 12:32:08 -07:00
|
|
|
EXPORT_SYMBOL(get_mem_type);
|
2007-04-21 02:47:29 -07:00
|
|
|
|
2015-08-12 16:01:52 -07:00
|
|
|
static pte_t *(*pte_offset_fixmap)(pmd_t *dir, unsigned long addr);
|
|
|
|
|
|
|
|
static pte_t bm_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS]
|
|
|
|
__aligned(PTE_HWTABLE_OFF + PTE_HWTABLE_SIZE) __initdata;
|
|
|
|
|
|
|
|
static pte_t * __init pte_offset_early_fixmap(pmd_t *dir, unsigned long addr)
|
|
|
|
{
|
|
|
|
return &bm_pte[pte_index(addr)];
|
|
|
|
}
|
|
|
|
|
|
|
|
static pte_t *pte_offset_late_fixmap(pmd_t *dir, unsigned long addr)
|
|
|
|
{
|
|
|
|
return pte_offset_kernel(dir, addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline pmd_t * __init fixmap_pmd(unsigned long addr)
|
|
|
|
{
|
2020-06-08 21:33:05 -07:00
|
|
|
return pmd_off_k(addr);
|
2015-08-12 16:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void __init early_fixmap_init(void)
|
|
|
|
{
|
|
|
|
pmd_t *pmd;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The early fixmap range spans multiple pmds, for which
|
|
|
|
* we are not prepared:
|
|
|
|
*/
|
2015-08-31 23:59:28 -07:00
|
|
|
BUILD_BUG_ON((__fix_to_virt(__end_of_early_ioremap_region) >> PMD_SHIFT)
|
2015-08-12 16:01:52 -07:00
|
|
|
!= FIXADDR_TOP >> PMD_SHIFT);
|
|
|
|
|
|
|
|
pmd = fixmap_pmd(FIXADDR_TOP);
|
|
|
|
pmd_populate_kernel(&init_mm, pmd, bm_pte);
|
|
|
|
|
|
|
|
pte_offset_fixmap = pte_offset_early_fixmap;
|
|
|
|
}
|
|
|
|
|
2014-04-04 14:27:49 -07:00
|
|
|
/*
|
|
|
|
* To avoid TLB flush broadcasts, this uses local_flush_tlb_kernel_range().
|
|
|
|
* As a result, this can only be called with preemption disabled, as under
|
|
|
|
* stop_machine().
|
|
|
|
*/
|
|
|
|
void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot)
|
|
|
|
{
|
|
|
|
unsigned long vaddr = __fix_to_virt(idx);
|
2015-08-12 16:01:52 -07:00
|
|
|
pte_t *pte = pte_offset_fixmap(pmd_off_k(vaddr), vaddr);
|
2014-04-04 14:27:49 -07:00
|
|
|
|
|
|
|
/* Make sure fixmap region does not exceed available allocation. */
|
ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled
The debugging code for kmap_local() doubles the number of per-CPU fixmap
slots allocated for kmap_local(), in order to use half of them as guard
regions. This causes the fixmap region to grow downwards beyond the start
of its reserved window if the supported number of CPUs is large, and collide
with the newly added virtual DT mapping right below it, which is obviously
not good.
One manifestation of this is EFI boot on a kernel built with NR_CPUS=32
and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting
in block entries below the fixmap region that the fixmap code misidentifies
as fixmap table entries, and subsequently tries to dereference using a
phys-to-virt translation that is only valid for lowmem. This results in a
cryptic splat such as the one below.
ftrace: allocating 45548 entries in 89 pages
8<--- cut here ---
Unable to handle kernel paging request at virtual address fc6006f0
pgd = (ptrval)
[fc6006f0] *pgd=80000040207003, *pmd=00000000
Internal error: Oops: a06 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382
Hardware name: Generic DT based system
PC is at cpu_ca15_set_pte_ext+0x24/0x30
LR is at __set_fixmap+0xe4/0x118
pc : [<c041ac9c>] lr : [<c04189d8>] psr: 400000d3
sp : c1601ed8 ip : 00400000 fp : 00800000
r10: 0000071f r9 : 00421000 r8 : 00c00000
r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f
r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0
Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
Control: 30c5387d Table: 40203000 DAC: 00000001
Process swapper (pid: 0, stack limit = 0x(ptrval))
So let's limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also,
fix the BUILD_BUG_ON() check that was supposed to catch this, by checking
whether the region grows below the start address rather than above the end
address.
Fixes: 2a15ba82fa6ca3f3 ("ARM: highmem: Switch to generic kmap atomic")
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2021-02-17 12:26:23 -07:00
|
|
|
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) < FIXADDR_START);
|
2014-04-04 14:27:49 -07:00
|
|
|
BUG_ON(idx >= __end_of_fixed_addresses);
|
|
|
|
|
2021-11-04 09:28:28 -07:00
|
|
|
/* We support only device mappings before pgprot_kernel is set. */
|
2017-04-10 03:13:59 -07:00
|
|
|
if (WARN_ON(pgprot_val(prot) != pgprot_val(FIXMAP_PAGE_IO) &&
|
2021-11-04 09:28:28 -07:00
|
|
|
pgprot_val(prot) && pgprot_val(pgprot_kernel) == 0))
|
2017-04-10 03:13:59 -07:00
|
|
|
return;
|
|
|
|
|
2014-04-04 14:27:49 -07:00
|
|
|
if (pgprot_val(prot))
|
|
|
|
set_pte_at(NULL, vaddr, pte,
|
|
|
|
pfn_pte(phys >> PAGE_SHIFT, prot));
|
|
|
|
else
|
|
|
|
pte_clear(NULL, vaddr, pte);
|
|
|
|
local_flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);
|
|
|
|
}
|
|
|
|
|
2022-07-11 00:05:57 -07:00
|
|
|
static pgprot_t protection_map[16] __ro_after_init = {
|
|
|
|
[VM_NONE] = __PAGE_NONE,
|
|
|
|
[VM_READ] = __PAGE_READONLY,
|
|
|
|
[VM_WRITE] = __PAGE_COPY,
|
|
|
|
[VM_WRITE | VM_READ] = __PAGE_COPY,
|
|
|
|
[VM_EXEC] = __PAGE_READONLY_EXEC,
|
|
|
|
[VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC,
|
|
|
|
[VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC,
|
|
|
|
[VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC,
|
|
|
|
[VM_SHARED] = __PAGE_NONE,
|
|
|
|
[VM_SHARED | VM_READ] = __PAGE_READONLY,
|
|
|
|
[VM_SHARED | VM_WRITE] = __PAGE_SHARED,
|
|
|
|
[VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED,
|
|
|
|
[VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC,
|
|
|
|
[VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC,
|
|
|
|
[VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC,
|
|
|
|
[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC
|
|
|
|
};
|
|
|
|
DECLARE_VM_GET_PAGE_PROT
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
|
|
|
* Adjust the PMD section entries according to the CPU in use.
|
|
|
|
*/
|
|
|
|
static void __init build_mem_type_table(void)
|
|
|
|
{
|
|
|
|
struct cachepolicy *cp;
|
|
|
|
unsigned int cr = get_cr();
|
2011-09-05 09:51:56 -07:00
|
|
|
pteval_t user_pgprot, kern_pgprot, vecs_pgprot;
|
2006-09-27 07:38:34 -07:00
|
|
|
int cpu_arch = cpu_architecture();
|
|
|
|
int i;
|
|
|
|
|
2007-07-20 03:42:24 -07:00
|
|
|
if (cpu_arch < CPU_ARCH_ARMv6) {
|
2006-09-27 07:38:34 -07:00
|
|
|
#if defined(CONFIG_CPU_DCACHE_DISABLE)
|
2007-07-20 03:42:24 -07:00
|
|
|
if (cachepolicy > CPOLICY_BUFFERED)
|
|
|
|
cachepolicy = CPOLICY_BUFFERED;
|
2006-09-27 07:38:34 -07:00
|
|
|
#elif defined(CONFIG_CPU_DCACHE_WRITETHROUGH)
|
2007-07-20 03:42:24 -07:00
|
|
|
if (cachepolicy > CPOLICY_WRITETHROUGH)
|
|
|
|
cachepolicy = CPOLICY_WRITETHROUGH;
|
2006-09-27 07:38:34 -07:00
|
|
|
#endif
|
2007-07-20 03:42:24 -07:00
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
if (cpu_arch < CPU_ARCH_ARMv5) {
|
|
|
|
if (cachepolicy >= CPOLICY_WRITEALLOC)
|
|
|
|
cachepolicy = CPOLICY_WRITEBACK;
|
|
|
|
ecc_mask = 0;
|
|
|
|
}
|
2014-05-27 12:34:28 -07:00
|
|
|
|
2014-06-02 01:29:37 -07:00
|
|
|
if (is_smp()) {
|
|
|
|
if (cachepolicy != CPOLICY_WRITEALLOC) {
|
|
|
|
pr_warn("Forcing write-allocate cache policy for SMP\n");
|
|
|
|
cachepolicy = CPOLICY_WRITEALLOC;
|
|
|
|
}
|
|
|
|
if (!(initial_pmd_value & PMD_SECT_S)) {
|
|
|
|
pr_warn("Forcing shared mappings for SMP\n");
|
|
|
|
initial_pmd_value |= PMD_SECT_S;
|
|
|
|
}
|
2014-05-27 12:34:28 -07:00
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
|
[ARM] 5241/1: provide ioremap_wc()
This patch provides an ARM implementation of ioremap_wc().
We use different page table attributes depending on which CPU we
are running on:
- Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
possible mapping types (CB=00/01/10/11). We can't use any of the
cached memory types (CB=10/11), since that breaks coherency with
peripheral devices. Both CB=00 and CB=01 are suitable for _wc, and
CB=01 (Uncached/Buffered) allows the hardware more freedom than
CB=00, so we'll use that.
(The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
but isn't allowed to merge them, but there is no other mapping type
we can use that allows the hardware to delay and merge stores, so
we'll go with CB=01.)
- XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
difference that on these platforms, CB=01 actually _does_ allow
merging stores. (If you want noncoalescing bufferable behavior
on Xscale v1/v2, you need to use XCB=101.)
- Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
in ARMv6 parlance).
The ARMv6 ARM explicitly says that any accesses to Normal memory can
be merged, which makes Normal memory more suitable for _wc mappings
than Device or Strongly Ordered memory, as the latter two mapping
types are guaranteed to maintain transaction number, size and order.
We use the Uncached variety of Normal mappings for the same reason
that we can't use C=1 mappings on ARMv5.
The xsc3 Architecture Specification documents TEXCB=00100 as being
Uncacheable and allowing coalescing of writes, which is also just
what we need.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05 05:17:11 -07:00
|
|
|
/*
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
* Strip out features not present on earlier architectures.
|
|
|
|
* Pre-ARMv5 CPUs don't have TEX bits. Pre-ARMv6 CPUs or those
|
|
|
|
* without extended page tables don't have the 'Shared' bit.
|
[ARM] 5241/1: provide ioremap_wc()
This patch provides an ARM implementation of ioremap_wc().
We use different page table attributes depending on which CPU we
are running on:
- Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
possible mapping types (CB=00/01/10/11). We can't use any of the
cached memory types (CB=10/11), since that breaks coherency with
peripheral devices. Both CB=00 and CB=01 are suitable for _wc, and
CB=01 (Uncached/Buffered) allows the hardware more freedom than
CB=00, so we'll use that.
(The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
but isn't allowed to merge them, but there is no other mapping type
we can use that allows the hardware to delay and merge stores, so
we'll go with CB=01.)
- XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
difference that on these platforms, CB=01 actually _does_ allow
merging stores. (If you want noncoalescing bufferable behavior
on Xscale v1/v2, you need to use XCB=101.)
- Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
in ARMv6 parlance).
The ARMv6 ARM explicitly says that any accesses to Normal memory can
be merged, which makes Normal memory more suitable for _wc mappings
than Device or Strongly Ordered memory, as the latter two mapping
types are guaranteed to maintain transaction number, size and order.
We use the Uncached variety of Normal mappings for the same reason
that we can't use C=1 mappings on ARMv5.
The xsc3 Architecture Specification documents TEXCB=00100 as being
Uncacheable and allowing coalescing of writes, which is also just
what we need.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05 05:17:11 -07:00
|
|
|
*/
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
if (cpu_arch < CPU_ARCH_ARMv5)
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++)
|
|
|
|
mem_types[i].prot_sect &= ~PMD_SECT_TEX(7);
|
|
|
|
if ((cpu_arch < CPU_ARCH_ARMv6 || !(cr & CR_XP)) && !cpu_is_xsc3())
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++)
|
|
|
|
mem_types[i].prot_sect &= ~PMD_SECT_S;
|
2006-09-27 07:38:34 -07:00
|
|
|
|
|
|
|
/*
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
* ARMv5 and lower, bit 4 must be set for page tables (was: cache
|
|
|
|
* "update-able on write" bit on ARM610). However, Xscale and
|
|
|
|
* Xscale3 require this bit to be cleared.
|
2006-09-27 07:38:34 -07:00
|
|
|
*/
|
ARM: make xscale iwmmxt code multiplatform aware
In a multiplatform configuration, we may end up building a kernel for
both Marvell PJ1 and an ARMv4 CPU implementation. In that case, the
xscale-cp0 code is built with gcc -march=armv4{,t}, which results in a
build error from the coprocessor instructions.
Since we know this code will only have to run on an actual xscale
processor, we can simply build the entire file for ARMv5TE.
Related to this, we need to handle the iWMMXT initialization sequence
differently during boot, to ensure we don't try to touch xscale
specific registers on other CPUs from the xscale_cp0_init initcall.
cpu_is_xscale() used to be hardcoded to '1' in any configuration that
enables any XScale-compatible core, but this breaks once we can have a
combined kernel with MMP1 and something else.
In this patch, I replace the existing cpu_is_xscale() macro with a new
cpu_is_xscale_family() macro that evaluates true for xscale, xsc3 and
mohawk, which makes the behavior more deterministic.
The two existing users of cpu_is_xscale() are modified accordingly,
but slightly change behavior for kernels that enable CPU_MOHAWK without
also enabling CPU_XSCALE or CPU_XSC3. Previously, these would leave leave
PMD_BIT4 in the page tables untouched, now they clear it as we've always
done for kernels that enable both MOHAWK and the support for the older
CPU types.
Since the previous behavior was inconsistent, I assume it was
unintentional.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-04-15 06:38:39 -07:00
|
|
|
if (cpu_is_xscale_family()) {
|
2007-05-05 12:03:35 -07:00
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++) {
|
2006-09-27 07:38:34 -07:00
|
|
|
mem_types[i].prot_sect &= ~PMD_BIT4;
|
2007-05-05 12:03:35 -07:00
|
|
|
mem_types[i].prot_l1 &= ~PMD_BIT4;
|
|
|
|
}
|
|
|
|
} else if (cpu_arch < CPU_ARCH_ARMv6) {
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++) {
|
2006-09-27 07:38:34 -07:00
|
|
|
if (mem_types[i].prot_l1)
|
|
|
|
mem_types[i].prot_l1 |= PMD_BIT4;
|
2007-05-05 12:03:35 -07:00
|
|
|
if (mem_types[i].prot_sect)
|
|
|
|
mem_types[i].prot_sect |= PMD_BIT4;
|
|
|
|
}
|
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
/*
|
|
|
|
* Mark the device areas according to the CPU/architecture.
|
|
|
|
*/
|
|
|
|
if (cpu_is_xsc3() || (cpu_arch >= CPU_ARCH_ARMv6 && (cr & CR_XP))) {
|
|
|
|
if (!cpu_is_xsc3()) {
|
|
|
|
/*
|
|
|
|
* Mark device regions on ARMv6+ as execute-never
|
|
|
|
* to prevent speculative instruction fetches.
|
|
|
|
*/
|
|
|
|
mem_types[MT_DEVICE].prot_sect |= PMD_SECT_XN;
|
|
|
|
mem_types[MT_DEVICE_NONSHARED].prot_sect |= PMD_SECT_XN;
|
|
|
|
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_XN;
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_XN;
|
2013-10-24 00:12:39 -07:00
|
|
|
|
|
|
|
/* Also setup NX memory mapping */
|
|
|
|
mem_types[MT_MEMORY_RW].prot_sect |= PMD_SECT_XN;
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
mem_types[MT_MEMORY_RO].prot_sect |= PMD_SECT_XN;
|
[ARM] mm: fix page table initialization
As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like. While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.
Tested on:
OMAP34xx (ARMv7),
OMAP24xx (ARMv6),
OMAP16xx (ARM926T, ARMv5),
PXA311 (Xscale3),
PXA272 (Xscale),
PXA255 (Xscale),
IXP42x (Xscale),
S3C2410 (ARM920T, ARMv4T),
ARM720T (ARMv4T)
StrongARM-110 (ARMv4)
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Ben Dooks <ben-linux@fluff.org>
Tested-by: Anders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-04 03:52:28 -07:00
|
|
|
}
|
|
|
|
if (cpu_arch >= CPU_ARCH_ARMv7 && (cr & CR_TRE)) {
|
|
|
|
/*
|
|
|
|
* For ARMv7 with TEX remapping,
|
|
|
|
* - shared device is SXCB=1100
|
|
|
|
* - nonshared device is SXCB=0100
|
|
|
|
* - write combine device mem is SXCB=0001
|
|
|
|
* (Uncached Normal memory)
|
|
|
|
*/
|
|
|
|
mem_types[MT_DEVICE].prot_sect |= PMD_SECT_TEX(1);
|
|
|
|
mem_types[MT_DEVICE_NONSHARED].prot_sect |= PMD_SECT_TEX(1);
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_BUFFERABLE;
|
|
|
|
} else if (cpu_is_xsc3()) {
|
|
|
|
/*
|
|
|
|
* For Xscale3,
|
|
|
|
* - shared device is TEXCB=00101
|
|
|
|
* - nonshared device is TEXCB=01000
|
|
|
|
* - write combine device mem is TEXCB=00100
|
|
|
|
* (Inner/Outer Uncacheable in xsc3 parlance)
|
|
|
|
*/
|
|
|
|
mem_types[MT_DEVICE].prot_sect |= PMD_SECT_TEX(1) | PMD_SECT_BUFFERED;
|
|
|
|
mem_types[MT_DEVICE_NONSHARED].prot_sect |= PMD_SECT_TEX(2);
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_TEX(1);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* For ARMv6 and ARMv7 without TEX remapping,
|
|
|
|
* - shared device is TEXCB=00001
|
|
|
|
* - nonshared device is TEXCB=01000
|
|
|
|
* - write combine device mem is TEXCB=00100
|
|
|
|
* (Uncached Normal in ARMv6 parlance).
|
|
|
|
*/
|
|
|
|
mem_types[MT_DEVICE].prot_sect |= PMD_SECT_BUFFERED;
|
|
|
|
mem_types[MT_DEVICE_NONSHARED].prot_sect |= PMD_SECT_TEX(2);
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_TEX(1);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* On others, write combining is "Uncached/Buffered"
|
|
|
|
*/
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_BUFFERABLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now deal with the memory-type mappings
|
|
|
|
*/
|
2006-09-27 07:38:34 -07:00
|
|
|
cp = &cache_policies[cachepolicy];
|
2008-09-06 12:04:59 -07:00
|
|
|
vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
|
|
|
|
|
2014-11-28 18:33:30 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2014-02-07 11:12:27 -07:00
|
|
|
/*
|
|
|
|
* We don't use domains on ARMv6 (since this causes problems with
|
|
|
|
* v6/v7 kernels), so we must use a separate memory type for user
|
|
|
|
* r/o, kernel r/w to map the vectors page.
|
|
|
|
*/
|
|
|
|
if (cpu_arch == CPU_ARCH_ARMv6)
|
|
|
|
vecs_pgprot |= L_PTE_MT_VECTORS;
|
2014-11-28 18:33:30 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check is it with support for the PXN bit
|
|
|
|
* in the Short-descriptor translation table format descriptors.
|
|
|
|
*/
|
|
|
|
if (cpu_arch == CPU_ARCH_ARMv7 &&
|
2015-12-28 21:47:00 -07:00
|
|
|
(read_cpuid_ext(CPUID_EXT_MMFR0) & 0xF) >= 4) {
|
2014-11-28 18:33:30 -07:00
|
|
|
user_pmd_table |= PMD_PXNTABLE;
|
|
|
|
}
|
2014-02-07 11:12:27 -07:00
|
|
|
#endif
|
2008-09-06 12:04:59 -07:00
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
|
|
|
* ARMv6 and above have extended page tables.
|
|
|
|
*/
|
|
|
|
if (cpu_arch >= CPU_ARCH_ARMv6 && (cr & CR_XP)) {
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
|
|
|
* Mark cache clean areas and XIP ROM read only
|
|
|
|
* from SVC mode and no access from userspace.
|
|
|
|
*/
|
|
|
|
mem_types[MT_ROM].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
|
|
|
|
mem_types[MT_MINICLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
|
|
|
|
mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
mem_types[MT_MEMORY_RO].prot_sect |= PMD_SECT_APX|PMD_SECT_AP_WRITE;
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2014-06-02 01:29:37 -07:00
|
|
|
/*
|
|
|
|
* If the initial page tables were created with the S bit
|
|
|
|
* set, then we need to do the same here for the same
|
|
|
|
* reasons given in early_cachepolicy().
|
|
|
|
*/
|
|
|
|
if (initial_pmd_value & PMD_SECT_S) {
|
2010-09-04 02:47:48 -07:00
|
|
|
user_pgprot |= L_PTE_SHARED;
|
|
|
|
kern_pgprot |= L_PTE_SHARED;
|
|
|
|
vecs_pgprot |= L_PTE_SHARED;
|
|
|
|
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
|
|
|
|
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_MEMORY_RWX].prot_pte |= L_PTE_SHARED;
|
2013-10-24 00:12:39 -07:00
|
|
|
mem_types[MT_MEMORY_RW].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_MEMORY_RW].prot_pte |= L_PTE_SHARED;
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
mem_types[MT_MEMORY_RO].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_MEMORY_RO].prot_pte |= L_PTE_SHARED;
|
2011-12-29 05:09:51 -07:00
|
|
|
mem_types[MT_MEMORY_DMA_READY].prot_pte |= L_PTE_SHARED;
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_sect |= PMD_SECT_S;
|
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_pte |= L_PTE_SHARED;
|
2010-09-04 02:47:48 -07:00
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.
On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."
If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.
TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:
http://www.spinics.net/lists/arm-kernel/msg54312.html
This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 12:11:43 -07:00
|
|
|
/*
|
|
|
|
* Non-cacheable Normal - intended for memory areas that must
|
|
|
|
* not cause dirty cache line writebacks when used
|
|
|
|
*/
|
|
|
|
if (cpu_arch >= CPU_ARCH_ARMv6) {
|
|
|
|
if (cpu_arch >= CPU_ARCH_ARMv7 && (cr & CR_TRE)) {
|
|
|
|
/* Non-cacheable Normal is XCB = 001 */
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_sect |=
|
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.
On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."
If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.
TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:
http://www.spinics.net/lists/arm-kernel/msg54312.html
This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 12:11:43 -07:00
|
|
|
PMD_SECT_BUFFERED;
|
|
|
|
} else {
|
|
|
|
/* For both ARMv6 and non-TEX-remapping ARMv7 */
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_sect |=
|
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.
On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."
If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.
TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:
http://www.spinics.net/lists/arm-kernel/msg54312.html
This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 12:11:43 -07:00
|
|
|
PMD_SECT_TEX(1);
|
|
|
|
}
|
|
|
|
} else {
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_sect |= PMD_SECT_BUFFERABLE;
|
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.
On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."
If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.
TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:
http://www.spinics.net/lists/arm-kernel/msg54312.html
This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 12:11:43 -07:00
|
|
|
}
|
|
|
|
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifdef CONFIG_ARM_LPAE
|
|
|
|
/*
|
|
|
|
* Do not generate access flag faults for the kernel mappings.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++) {
|
|
|
|
mem_types[i].prot_pte |= PTE_EXT_AF;
|
2012-05-15 07:01:16 -07:00
|
|
|
if (mem_types[i].prot_sect)
|
|
|
|
mem_types[i].prot_sect |= PMD_SECT_AF;
|
2011-11-22 10:30:29 -07:00
|
|
|
}
|
|
|
|
kern_pgprot |= PTE_EXT_AF;
|
|
|
|
vecs_pgprot |= PTE_EXT_AF;
|
2014-11-28 18:33:30 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set PXN for user mappings
|
|
|
|
*/
|
|
|
|
user_pgprot |= PTE_EXT_PXN;
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
for (i = 0; i < 16; i++) {
|
2012-09-18 11:18:35 -07:00
|
|
|
pteval_t v = pgprot_val(protection_map[i]);
|
2008-09-06 12:04:59 -07:00
|
|
|
protection_map[i] = __pgprot(v | user_pgprot);
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2008-09-06 12:04:59 -07:00
|
|
|
mem_types[MT_LOW_VECTORS].prot_pte |= vecs_pgprot;
|
|
|
|
mem_types[MT_HIGH_VECTORS].prot_pte |= vecs_pgprot;
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2007-02-11 05:45:13 -07:00
|
|
|
pgprot_user = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | user_pgprot);
|
2006-09-27 07:38:34 -07:00
|
|
|
pgprot_kernel = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG |
|
2010-11-16 01:40:36 -07:00
|
|
|
L_PTE_DIRTY | kern_pgprot);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
|
|
|
mem_types[MT_LOW_VECTORS].prot_l1 |= ecc_mask;
|
|
|
|
mem_types[MT_HIGH_VECTORS].prot_l1 |= ecc_mask;
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX].prot_sect |= ecc_mask | cp->pmd;
|
|
|
|
mem_types[MT_MEMORY_RWX].prot_pte |= kern_pgprot;
|
2013-10-24 00:12:39 -07:00
|
|
|
mem_types[MT_MEMORY_RW].prot_sect |= ecc_mask | cp->pmd;
|
|
|
|
mem_types[MT_MEMORY_RW].prot_pte |= kern_pgprot;
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
mem_types[MT_MEMORY_RO].prot_sect |= ecc_mask | cp->pmd;
|
|
|
|
mem_types[MT_MEMORY_RO].prot_pte |= kern_pgprot;
|
2011-12-29 05:09:51 -07:00
|
|
|
mem_types[MT_MEMORY_DMA_READY].prot_pte |= kern_pgprot;
|
2013-10-24 02:26:40 -07:00
|
|
|
mem_types[MT_MEMORY_RWX_NONCACHED].prot_sect |= ecc_mask;
|
2006-09-27 07:38:34 -07:00
|
|
|
mem_types[MT_ROM].prot_sect |= cp->pmd;
|
|
|
|
|
|
|
|
switch (cp->pmd) {
|
|
|
|
case PMD_SECT_WT:
|
|
|
|
mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_WT;
|
|
|
|
break;
|
|
|
|
case PMD_SECT_WB:
|
|
|
|
case PMD_SECT_WBWA:
|
|
|
|
mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_WB;
|
|
|
|
break;
|
|
|
|
}
|
2013-11-07 04:49:53 -07:00
|
|
|
pr_info("Memory policy: %sData cache %s\n",
|
|
|
|
ecc_mask ? "ECC enabled, " : "", cp->policy);
|
2007-04-21 01:59:44 -07:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mem_types); i++) {
|
|
|
|
struct mem_type *t = &mem_types[i];
|
|
|
|
if (t->prot_l1)
|
|
|
|
t->prot_l1 |= PMD_DOMAIN(t->domain);
|
|
|
|
if (t->prot_sect)
|
|
|
|
t->prot_sect |= PMD_DOMAIN(t->domain);
|
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2010-09-13 08:01:24 -07:00
|
|
|
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
|
|
|
|
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
|
|
|
|
unsigned long size, pgprot_t vma_prot)
|
|
|
|
{
|
|
|
|
if (!pfn_valid(pfn))
|
|
|
|
return pgprot_noncached(vma_prot);
|
|
|
|
else if (file->f_flags & O_SYNC)
|
|
|
|
return pgprot_writecombine(vma_prot);
|
|
|
|
return vma_prot;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(phys_mem_access_prot);
|
|
|
|
#endif
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
#define vectors_base() (vectors_high() ? 0xffff0000 : 0)
|
|
|
|
|
2011-08-24 21:35:59 -07:00
|
|
|
static void __init *early_alloc(unsigned long sz)
|
|
|
|
{
|
2019-03-11 23:30:31 -07:00
|
|
|
void *ptr = memblock_alloc(sz, sz);
|
|
|
|
|
|
|
|
if (!ptr)
|
|
|
|
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
|
|
|
|
__func__, sz, sz);
|
|
|
|
|
|
|
|
return ptr;
|
2011-08-24 21:35:59 -07:00
|
|
|
}
|
|
|
|
|
2015-04-29 01:04:17 -07:00
|
|
|
static void *__init late_alloc(unsigned long sz)
|
|
|
|
{
|
2023-08-07 16:04:59 -07:00
|
|
|
void *ptdesc = pagetable_alloc(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM,
|
|
|
|
get_order(sz));
|
2015-04-29 01:04:17 -07:00
|
|
|
|
2023-08-07 16:04:59 -07:00
|
|
|
if (!ptdesc || !pagetable_pte_ctor(ptdesc))
|
2016-07-28 11:48:44 -07:00
|
|
|
BUG();
|
2023-08-07 16:04:59 -07:00
|
|
|
return ptdesc_to_virt(ptdesc);
|
2015-04-29 01:04:17 -07:00
|
|
|
}
|
|
|
|
|
2016-03-17 14:19:11 -07:00
|
|
|
static pte_t * __init arm_pte_alloc(pmd_t *pmd, unsigned long addr,
|
2015-09-15 05:59:14 -07:00
|
|
|
unsigned long prot,
|
|
|
|
void *(*alloc)(unsigned long sz))
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
2007-04-21 02:21:28 -07:00
|
|
|
if (pmd_none(*pmd)) {
|
2015-09-15 05:59:14 -07:00
|
|
|
pte_t *pte = alloc(PTE_HWTABLE_OFF + PTE_HWTABLE_SIZE);
|
2010-11-15 17:16:01 -07:00
|
|
|
__pmd_populate(pmd, __pa(pte), prot);
|
2007-04-21 02:21:28 -07:00
|
|
|
}
|
2010-07-01 10:33:29 -07:00
|
|
|
BUG_ON(pmd_bad(*pmd));
|
|
|
|
return pte_offset_kernel(pmd, addr);
|
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2015-09-15 05:59:14 -07:00
|
|
|
static pte_t * __init early_pte_alloc(pmd_t *pmd, unsigned long addr,
|
|
|
|
unsigned long prot)
|
|
|
|
{
|
2016-03-17 14:19:11 -07:00
|
|
|
return arm_pte_alloc(pmd, addr, prot, early_alloc);
|
2015-09-15 05:59:14 -07:00
|
|
|
}
|
|
|
|
|
2010-07-01 10:33:29 -07:00
|
|
|
static void __init alloc_init_pte(pmd_t *pmd, unsigned long addr,
|
|
|
|
unsigned long end, unsigned long pfn,
|
2015-09-15 05:59:14 -07:00
|
|
|
const struct mem_type *type,
|
2015-11-17 00:46:47 -07:00
|
|
|
void *(*alloc)(unsigned long sz),
|
|
|
|
bool ng)
|
2010-07-01 10:33:29 -07:00
|
|
|
{
|
2016-03-17 14:19:11 -07:00
|
|
|
pte_t *pte = arm_pte_alloc(pmd, addr, type->prot_l1, alloc);
|
2007-04-21 02:21:28 -07:00
|
|
|
do {
|
2015-11-17 00:46:47 -07:00
|
|
|
set_pte_ext(pte, pfn_pte(pfn, __pgprot(type->prot_pte)),
|
|
|
|
ng ? PTE_EXT_NG : 0);
|
2007-04-21 02:21:28 -07:00
|
|
|
pfn++;
|
|
|
|
} while (pte++, addr += PAGE_SIZE, addr != end);
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2013-06-07 04:15:45 -07:00
|
|
|
static void __init __map_init_section(pmd_t *pmd, unsigned long addr,
|
2013-03-18 04:24:04 -07:00
|
|
|
unsigned long end, phys_addr_t phys,
|
2015-11-17 00:46:47 -07:00
|
|
|
const struct mem_type *type, bool ng)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
2013-06-07 04:15:45 -07:00
|
|
|
pmd_t *p = pmd;
|
|
|
|
|
2013-03-18 04:24:04 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2007-04-21 02:21:28 -07:00
|
|
|
/*
|
2013-03-18 04:24:04 -07:00
|
|
|
* In classic MMU format, puds and pmds are folded in to
|
|
|
|
* the pgds. pmd_offset gives the PGD entry. PGDs refer to a
|
|
|
|
* group of L1 entries making up one logical pointer to
|
|
|
|
* an L2 table (2MB), where as PMDs refer to the individual
|
|
|
|
* L1 entries (1MB). Hence increment to get the correct
|
|
|
|
* offset for odd 1MB sections.
|
|
|
|
* (See arch/arm/include/asm/pgtable-2level.h)
|
2007-04-21 02:21:28 -07:00
|
|
|
*/
|
2013-03-18 04:24:04 -07:00
|
|
|
if (addr & SECTION_SIZE)
|
|
|
|
pmd++;
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2013-03-18 04:24:04 -07:00
|
|
|
do {
|
2015-11-17 00:46:47 -07:00
|
|
|
*pmd = __pmd(phys | type->prot_sect | (ng ? PMD_SECT_nG : 0));
|
2013-03-18 04:24:04 -07:00
|
|
|
phys += SECTION_SIZE;
|
|
|
|
} while (pmd++, addr += SECTION_SIZE, addr != end);
|
2007-04-21 02:21:28 -07:00
|
|
|
|
2013-06-07 04:15:45 -07:00
|
|
|
flush_pmd_entry(p);
|
2013-03-18 04:24:04 -07:00
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2013-03-18 04:24:04 -07:00
|
|
|
static void __init alloc_init_pmd(pud_t *pud, unsigned long addr,
|
|
|
|
unsigned long end, phys_addr_t phys,
|
2015-09-15 05:59:14 -07:00
|
|
|
const struct mem_type *type,
|
2015-11-17 00:46:47 -07:00
|
|
|
void *(*alloc)(unsigned long sz), bool ng)
|
2013-03-18 04:24:04 -07:00
|
|
|
{
|
|
|
|
pmd_t *pmd = pmd_offset(pud, addr);
|
|
|
|
unsigned long next;
|
|
|
|
|
|
|
|
do {
|
2007-04-21 02:21:28 -07:00
|
|
|
/*
|
2013-03-18 04:24:04 -07:00
|
|
|
* With LPAE, we must loop over to map
|
|
|
|
* all the pmds for the given range.
|
2007-04-21 02:21:28 -07:00
|
|
|
*/
|
2013-03-18 04:24:04 -07:00
|
|
|
next = pmd_addr_end(addr, end);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try a section mapping - addr, next and phys must all be
|
|
|
|
* aligned to a section boundary.
|
|
|
|
*/
|
|
|
|
if (type->prot_sect &&
|
|
|
|
((addr | next | phys) & ~SECTION_MASK) == 0) {
|
2015-11-17 00:46:47 -07:00
|
|
|
__map_init_section(pmd, addr, next, phys, type, ng);
|
2013-03-18 04:24:04 -07:00
|
|
|
} else {
|
|
|
|
alloc_init_pte(pmd, addr, next,
|
2015-11-17 00:46:47 -07:00
|
|
|
__phys_to_pfn(phys), type, alloc, ng);
|
2013-03-18 04:24:04 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
phys += next - addr;
|
|
|
|
|
|
|
|
} while (pmd++, addr = next, addr != end);
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2020-06-04 16:46:19 -07:00
|
|
|
static void __init alloc_init_pud(p4d_t *p4d, unsigned long addr,
|
2012-07-10 11:41:17 -07:00
|
|
|
unsigned long end, phys_addr_t phys,
|
2015-09-15 05:59:14 -07:00
|
|
|
const struct mem_type *type,
|
2015-11-17 00:46:47 -07:00
|
|
|
void *(*alloc)(unsigned long sz), bool ng)
|
2010-11-21 09:27:49 -07:00
|
|
|
{
|
2020-06-04 16:46:19 -07:00
|
|
|
pud_t *pud = pud_offset(p4d, addr);
|
2010-11-21 09:27:49 -07:00
|
|
|
unsigned long next;
|
|
|
|
|
|
|
|
do {
|
|
|
|
next = pud_addr_end(addr, end);
|
2015-11-17 00:46:47 -07:00
|
|
|
alloc_init_pmd(pud, addr, next, phys, type, alloc, ng);
|
2010-11-21 09:27:49 -07:00
|
|
|
phys += next - addr;
|
|
|
|
} while (pud++, addr = next, addr != end);
|
|
|
|
}
|
|
|
|
|
2020-06-04 16:46:19 -07:00
|
|
|
static void __init alloc_init_p4d(pgd_t *pgd, unsigned long addr,
|
|
|
|
unsigned long end, phys_addr_t phys,
|
|
|
|
const struct mem_type *type,
|
|
|
|
void *(*alloc)(unsigned long sz), bool ng)
|
|
|
|
{
|
|
|
|
p4d_t *p4d = p4d_offset(pgd, addr);
|
|
|
|
unsigned long next;
|
|
|
|
|
|
|
|
do {
|
|
|
|
next = p4d_addr_end(addr, end);
|
|
|
|
alloc_init_pud(p4d, addr, next, phys, type, alloc, ng);
|
|
|
|
phys += next - addr;
|
|
|
|
} while (p4d++, addr = next, addr != end);
|
|
|
|
}
|
|
|
|
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2015-09-15 05:50:22 -07:00
|
|
|
static void __init create_36bit_mapping(struct mm_struct *mm,
|
|
|
|
struct map_desc *md,
|
2015-11-17 00:46:47 -07:00
|
|
|
const struct mem_type *type,
|
|
|
|
bool ng)
|
2007-04-21 02:16:48 -07:00
|
|
|
{
|
2010-11-15 17:16:01 -07:00
|
|
|
unsigned long addr, length, end;
|
|
|
|
phys_addr_t phys;
|
2007-04-21 02:16:48 -07:00
|
|
|
pgd_t *pgd;
|
|
|
|
|
|
|
|
addr = md->virtual;
|
2011-02-15 04:42:57 -07:00
|
|
|
phys = __pfn_to_phys(md->pfn);
|
2007-04-21 02:16:48 -07:00
|
|
|
length = PAGE_ALIGN(md->length);
|
|
|
|
|
|
|
|
if (!(cpu_architecture() >= CPU_ARCH_ARMv6 || cpu_is_xsc3())) {
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_err("MM: CPU does not support supersection mapping for 0x%08llx at 0x%08lx\n",
|
2011-02-15 06:31:37 -07:00
|
|
|
(long long)__pfn_to_phys((u64)md->pfn), addr);
|
2007-04-21 02:16:48 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* N.B. ARMv6 supersections are only defined to work with domain 0.
|
|
|
|
* Since domain assignments can in fact be arbitrary, the
|
|
|
|
* 'domain == 0' check below is required to insure that ARMv6
|
|
|
|
* supersections are only allocated for domain 0 regardless
|
|
|
|
* of the actual domain assignments in use.
|
|
|
|
*/
|
|
|
|
if (type->domain) {
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_err("MM: invalid domain in supersection mapping for 0x%08llx at 0x%08lx\n",
|
2011-02-15 06:31:37 -07:00
|
|
|
(long long)__pfn_to_phys((u64)md->pfn), addr);
|
2007-04-21 02:16:48 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((addr | length | __pfn_to_phys(md->pfn)) & ~SUPERSECTION_MASK) {
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_err("MM: cannot create mapping for 0x%08llx at 0x%08lx invalid alignment\n",
|
2011-02-15 06:31:37 -07:00
|
|
|
(long long)__pfn_to_phys((u64)md->pfn), addr);
|
2007-04-21 02:16:48 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Shift bits [35:32] of address into bits [23:20] of PMD
|
|
|
|
* (See ARMv6 spec).
|
|
|
|
*/
|
|
|
|
phys |= (((md->pfn >> (32 - PAGE_SHIFT)) & 0xF) << 20);
|
|
|
|
|
2015-09-15 05:50:22 -07:00
|
|
|
pgd = pgd_offset(mm, addr);
|
2007-04-21 02:16:48 -07:00
|
|
|
end = addr + length;
|
|
|
|
do {
|
2020-06-04 16:46:19 -07:00
|
|
|
p4d_t *p4d = p4d_offset(pgd, addr);
|
|
|
|
pud_t *pud = pud_offset(p4d, addr);
|
2010-11-21 09:27:49 -07:00
|
|
|
pmd_t *pmd = pmd_offset(pud, addr);
|
2007-04-21 02:16:48 -07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 16; i++)
|
2015-11-17 00:46:47 -07:00
|
|
|
*pmd++ = __pmd(phys | type->prot_sect | PMD_SECT_SUPER |
|
|
|
|
(ng ? PMD_SECT_nG : 0));
|
2007-04-21 02:16:48 -07:00
|
|
|
|
|
|
|
addr += SUPERSECTION_SIZE;
|
|
|
|
phys += SUPERSECTION_SIZE;
|
|
|
|
pgd += SUPERSECTION_SIZE >> PGDIR_SHIFT;
|
|
|
|
} while (addr != end);
|
|
|
|
}
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif /* !CONFIG_ARM_LPAE */
|
2007-04-21 02:16:48 -07:00
|
|
|
|
2015-09-15 05:59:14 -07:00
|
|
|
static void __init __create_mapping(struct mm_struct *mm, struct map_desc *md,
|
2015-11-17 00:46:47 -07:00
|
|
|
void *(*alloc)(unsigned long sz),
|
|
|
|
bool ng)
|
2006-09-27 07:38:34 -07:00
|
|
|
{
|
2011-02-15 04:42:57 -07:00
|
|
|
unsigned long addr, length, end;
|
|
|
|
phys_addr_t phys;
|
2007-04-21 02:05:32 -07:00
|
|
|
const struct mem_type *type;
|
2007-04-21 02:21:28 -07:00
|
|
|
pgd_t *pgd;
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2007-04-21 02:05:32 -07:00
|
|
|
type = &mem_types[md->type];
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
|
|
|
* Catch 36-bit addresses
|
|
|
|
*/
|
2007-04-21 02:16:48 -07:00
|
|
|
if (md->pfn >= 0x100000) {
|
2015-11-17 00:46:47 -07:00
|
|
|
create_36bit_mapping(mm, md, type, ng);
|
2007-04-21 02:16:48 -07:00
|
|
|
return;
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2007-07-04 13:16:33 -07:00
|
|
|
addr = md->virtual & PAGE_MASK;
|
2011-02-15 04:42:57 -07:00
|
|
|
phys = __pfn_to_phys(md->pfn);
|
2007-07-04 13:16:33 -07:00
|
|
|
length = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK));
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2007-04-21 02:21:28 -07:00
|
|
|
if (type->prot_l1 == 0 && ((addr | phys | length) & ~SECTION_MASK)) {
|
2014-10-28 04:26:42 -07:00
|
|
|
pr_warn("BUG: map for 0x%08llx at 0x%08lx can not be mapped using pages, ignoring.\n",
|
|
|
|
(long long)__pfn_to_phys(md->pfn), addr);
|
2006-09-27 07:38:34 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-15 05:50:22 -07:00
|
|
|
pgd = pgd_offset(mm, addr);
|
2007-04-21 02:21:28 -07:00
|
|
|
end = addr + length;
|
|
|
|
do {
|
|
|
|
unsigned long next = pgd_addr_end(addr, end);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2020-06-04 16:46:19 -07:00
|
|
|
alloc_init_p4d(pgd, addr, next, phys, type, alloc, ng);
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2007-04-21 02:21:28 -07:00
|
|
|
phys += next - addr;
|
|
|
|
addr = next;
|
|
|
|
} while (pgd++, addr != end);
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2015-09-15 05:50:22 -07:00
|
|
|
/*
|
|
|
|
* Create the page directory entries and any necessary
|
|
|
|
* page tables for the mapping specified by `md'. We
|
|
|
|
* are able to cope here with varying sizes and address
|
|
|
|
* offsets, and we take full advantage of sections and
|
|
|
|
* supersections.
|
|
|
|
*/
|
|
|
|
static void __init create_mapping(struct map_desc *md)
|
|
|
|
{
|
|
|
|
if (md->virtual != vectors_base() && md->virtual < TASK_SIZE) {
|
|
|
|
pr_warn("BUG: not creating mapping for 0x%08llx at 0x%08lx in user region\n",
|
|
|
|
(long long)__pfn_to_phys((u64)md->pfn), md->virtual);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
if (md->type == MT_DEVICE &&
|
2015-09-15 05:50:22 -07:00
|
|
|
md->virtual >= PAGE_OFFSET && md->virtual < FIXADDR_START &&
|
|
|
|
(md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
|
|
|
|
pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
|
|
|
|
(long long)__pfn_to_phys((u64)md->pfn), md->virtual);
|
|
|
|
}
|
|
|
|
|
2015-11-17 00:46:47 -07:00
|
|
|
__create_mapping(&init_mm, md, early_alloc, false);
|
2015-09-15 05:50:22 -07:00
|
|
|
}
|
|
|
|
|
2015-04-29 01:04:17 -07:00
|
|
|
void __init create_mapping_late(struct mm_struct *mm, struct map_desc *md,
|
|
|
|
bool ng)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_ARM_LPAE
|
2020-06-04 16:46:19 -07:00
|
|
|
p4d_t *p4d;
|
|
|
|
pud_t *pud;
|
|
|
|
|
|
|
|
p4d = p4d_alloc(mm, pgd_offset(mm, md->virtual), md->virtual);
|
2020-06-24 00:51:49 -07:00
|
|
|
if (WARN_ON(!p4d))
|
2020-06-04 16:46:19 -07:00
|
|
|
return;
|
|
|
|
pud = pud_alloc(mm, p4d, md->virtual);
|
2015-04-29 01:04:17 -07:00
|
|
|
if (WARN_ON(!pud))
|
|
|
|
return;
|
|
|
|
pmd_alloc(mm, pud, 0);
|
|
|
|
#endif
|
|
|
|
__create_mapping(mm, md, late_alloc, ng);
|
|
|
|
}
|
|
|
|
|
2006-09-27 07:38:34 -07:00
|
|
|
/*
|
|
|
|
* Create the architecture specific mappings
|
|
|
|
*/
|
|
|
|
void __init iotable_init(struct map_desc *io_desc, int nr)
|
|
|
|
{
|
2011-08-24 21:35:59 -07:00
|
|
|
struct map_desc *md;
|
|
|
|
struct vm_struct *vm;
|
2013-02-08 22:28:06 -07:00
|
|
|
struct static_vm *svm;
|
2011-08-24 21:35:59 -07:00
|
|
|
|
|
|
|
if (!nr)
|
|
|
|
return;
|
2006-09-27 07:38:34 -07:00
|
|
|
|
2019-03-07 17:31:10 -07:00
|
|
|
svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
|
2019-03-11 23:30:31 -07:00
|
|
|
if (!svm)
|
|
|
|
panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
|
|
|
|
__func__, sizeof(*svm) * nr, __alignof__(*svm));
|
2011-08-24 21:35:59 -07:00
|
|
|
|
|
|
|
for (md = io_desc; nr; md++, nr--) {
|
|
|
|
create_mapping(md);
|
2013-02-08 22:28:06 -07:00
|
|
|
|
|
|
|
vm = &svm->vm;
|
2011-08-24 21:35:59 -07:00
|
|
|
vm->addr = (void *)(md->virtual & PAGE_MASK);
|
|
|
|
vm->size = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK));
|
2012-02-29 17:10:58 -07:00
|
|
|
vm->phys_addr = __pfn_to_phys(md->pfn);
|
|
|
|
vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
|
2011-09-15 22:14:23 -07:00
|
|
|
vm->flags |= VM_ARM_MTYPE(md->type);
|
2011-08-24 21:35:59 -07:00
|
|
|
vm->caller = iotable_init;
|
2013-02-08 22:28:06 -07:00
|
|
|
add_static_vm_early(svm++);
|
2011-08-24 21:35:59 -07:00
|
|
|
}
|
2006-09-27 07:38:34 -07:00
|
|
|
}
|
|
|
|
|
2012-02-29 17:10:58 -07:00
|
|
|
void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
|
|
|
|
void *caller)
|
|
|
|
{
|
|
|
|
struct vm_struct *vm;
|
2013-02-08 22:28:06 -07:00
|
|
|
struct static_vm *svm;
|
|
|
|
|
2019-03-07 17:31:10 -07:00
|
|
|
svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
|
2019-03-11 23:30:31 -07:00
|
|
|
if (!svm)
|
|
|
|
panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
|
|
|
|
__func__, sizeof(*svm), __alignof__(*svm));
|
2012-02-29 17:10:58 -07:00
|
|
|
|
2013-02-08 22:28:06 -07:00
|
|
|
vm = &svm->vm;
|
2012-02-29 17:10:58 -07:00
|
|
|
vm->addr = (void *)addr;
|
|
|
|
vm->size = size;
|
2012-09-04 06:01:37 -07:00
|
|
|
vm->flags = VM_IOREMAP | VM_ARM_EMPTY_MAPPING;
|
2012-02-29 17:10:58 -07:00
|
|
|
vm->caller = caller;
|
2013-02-08 22:28:06 -07:00
|
|
|
add_static_vm_early(svm);
|
2012-02-29 17:10:58 -07:00
|
|
|
}
|
|
|
|
|
2012-06-27 09:28:57 -07:00
|
|
|
#ifndef CONFIG_ARM_LPAE
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The Linux PMD is made of two consecutive section entries covering 2MB
|
|
|
|
* (see definition in include/asm/pgtable-2level.h). However a call to
|
|
|
|
* create_mapping() may optimize static mappings by using individual
|
|
|
|
* 1MB section mappings. This leaves the actual PMD potentially half
|
|
|
|
* initialized if the top or bottom section entry isn't used, leaving it
|
|
|
|
* open to problems if a subsequent ioremap() or vmalloc() tries to use
|
|
|
|
* the virtual space left free by that unused section entry.
|
|
|
|
*
|
|
|
|
* Let's avoid the issue by inserting dummy vm entries covering the unused
|
|
|
|
* PMD halves once the static mappings are in place.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void __init pmd_empty_section_gap(unsigned long addr)
|
|
|
|
{
|
2012-02-29 17:10:58 -07:00
|
|
|
vm_reserve_area_early(addr, SECTION_SIZE, pmd_empty_section_gap);
|
2012-06-27 09:28:57 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __init fill_pmd_gaps(void)
|
|
|
|
{
|
2013-02-08 22:28:06 -07:00
|
|
|
struct static_vm *svm;
|
2012-06-27 09:28:57 -07:00
|
|
|
struct vm_struct *vm;
|
|
|
|
unsigned long addr, next = 0;
|
|
|
|
pmd_t *pmd;
|
|
|
|
|
2013-02-08 22:28:06 -07:00
|
|
|
list_for_each_entry(svm, &static_vmlist, list) {
|
|
|
|
vm = &svm->vm;
|
2012-06-27 09:28:57 -07:00
|
|
|
addr = (unsigned long)vm->addr;
|
|
|
|
if (addr < next)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if this vm starts on an odd section boundary.
|
|
|
|
* If so and the first section entry for this PMD is free
|
|
|
|
* then we block the corresponding virtual address.
|
|
|
|
*/
|
|
|
|
if ((addr & ~PMD_MASK) == SECTION_SIZE) {
|
|
|
|
pmd = pmd_off_k(addr);
|
|
|
|
if (pmd_none(*pmd))
|
|
|
|
pmd_empty_section_gap(addr & PMD_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Then check if this vm ends on an odd section boundary.
|
|
|
|
* If so and the second section entry for this PMD is empty
|
|
|
|
* then we block the corresponding virtual address.
|
|
|
|
*/
|
|
|
|
addr += vm->size;
|
|
|
|
if ((addr & ~PMD_MASK) == SECTION_SIZE) {
|
|
|
|
pmd = pmd_off_k(addr) + 1;
|
|
|
|
if (pmd_none(*pmd))
|
|
|
|
pmd_empty_section_gap(addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* no need to look at any vm entry until we hit the next PMD */
|
|
|
|
next = (addr + PMD_SIZE - 1) & PMD_MASK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
#define fill_pmd_gaps() do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
2012-02-29 17:10:58 -07:00
|
|
|
#if defined(CONFIG_PCI) && !defined(CONFIG_NEED_MACH_IO_H)
|
|
|
|
static void __init pci_reserve_io(void)
|
|
|
|
{
|
2013-02-08 22:28:06 -07:00
|
|
|
struct static_vm *svm;
|
2012-02-29 17:10:58 -07:00
|
|
|
|
2013-02-08 22:28:06 -07:00
|
|
|
svm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
|
|
|
|
if (svm)
|
|
|
|
return;
|
2012-02-29 17:10:58 -07:00
|
|
|
|
|
|
|
vm_reserve_area_early(PCI_IO_VIRT_BASE, SZ_2M, pci_reserve_io);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
#define pci_reserve_io() do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
ARM: implement debug_ll_io_init()
When using DEBUG_LL, the UART's (or other HW's) registers are mapped
into early page tables based on the results of assembly macro addruart.
Later, when the page tables are replaced, the same virtual address must
remain valid. Historically, this has been ensured by using defines from
<mach/iomap.h> in both the implementation of addruart, and the machine's
.map_io() function. However, with the move to single zImage, we wish to
remove <mach/iomap.h>. To enable this, the macro addruart may be used
when constructing the late page tables too; addruart is exposed as a
C function debug_ll_addr(), and used to set up the required mapping in
debug_ll_io_init(), which may called on an opt-in basis from a machine's
.map_io() function.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
[swarren: Mask map.virtual with PAGE_MASK. Checked for NULL results from
debug_ll_addr (e.g. when selected UART isn't valid). Fixed compile when
either !CONFIG_DEBUG_LL or CONFIG_DEBUG_SEMIHOSTING.]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2012-10-22 10:42:54 -07:00
|
|
|
#ifdef CONFIG_DEBUG_LL
|
|
|
|
void __init debug_ll_io_init(void)
|
|
|
|
{
|
|
|
|
struct map_desc map;
|
|
|
|
|
|
|
|
debug_ll_addr(&map.pfn, &map.virtual);
|
|
|
|
if (!map.pfn || !map.virtual)
|
|
|
|
return;
|
|
|
|
map.pfn = __phys_to_pfn(map.pfn);
|
|
|
|
map.virtual &= PAGE_MASK;
|
|
|
|
map.length = PAGE_SIZE;
|
|
|
|
map.type = MT_DEVICE;
|
2013-07-05 16:25:51 -07:00
|
|
|
iotable_init(&map, 1);
|
ARM: implement debug_ll_io_init()
When using DEBUG_LL, the UART's (or other HW's) registers are mapped
into early page tables based on the results of assembly macro addruart.
Later, when the page tables are replaced, the same virtual address must
remain valid. Historically, this has been ensured by using defines from
<mach/iomap.h> in both the implementation of addruart, and the machine's
.map_io() function. However, with the move to single zImage, we wish to
remove <mach/iomap.h>. To enable this, the macro addruart may be used
when constructing the late page tables too; addruart is exposed as a
C function debug_ll_addr(), and used to set up the required mapping in
debug_ll_io_init(), which may called on an opt-in basis from a machine's
.map_io() function.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
[swarren: Mask map.virtual with PAGE_MASK. Checked for NULL results from
debug_ll_addr (e.g. when selected UART isn't valid). Fixed compile when
either !CONFIG_DEBUG_LL or CONFIG_DEBUG_SEMIHOSTING.]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2012-10-22 10:42:54 -07:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2021-05-28 03:01:40 -07:00
|
|
|
static unsigned long __initdata vmalloc_size = 240 * SZ_1M;
|
2008-09-30 11:31:44 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* vmalloc=size forces the vmalloc area to be exactly 'size'
|
|
|
|
* bytes. This can be used to increase (or decrease) the vmalloc
|
2021-05-28 03:03:58 -07:00
|
|
|
* area - the default is 240MiB.
|
2008-09-30 11:31:44 -07:00
|
|
|
*/
|
2010-01-11 15:17:34 -07:00
|
|
|
static int __init early_vmalloc(char *arg)
|
2008-09-30 11:31:44 -07:00
|
|
|
{
|
2010-05-22 08:20:14 -07:00
|
|
|
unsigned long vmalloc_reserve = memparse(arg, NULL);
|
2021-05-18 04:40:21 -07:00
|
|
|
unsigned long vmalloc_max;
|
2008-09-30 11:31:44 -07:00
|
|
|
|
|
|
|
if (vmalloc_reserve < SZ_16M) {
|
|
|
|
vmalloc_reserve = SZ_16M;
|
2021-05-28 03:03:58 -07:00
|
|
|
pr_warn("vmalloc area is too small, limiting to %luMiB\n",
|
2008-09-30 11:31:44 -07:00
|
|
|
vmalloc_reserve >> 20);
|
|
|
|
}
|
2008-09-19 07:43:06 -07:00
|
|
|
|
2021-05-18 04:53:30 -07:00
|
|
|
vmalloc_max = VMALLOC_END - (PAGE_OFFSET + SZ_32M + VMALLOC_OFFSET);
|
2021-05-18 04:40:21 -07:00
|
|
|
if (vmalloc_reserve > vmalloc_max) {
|
|
|
|
vmalloc_reserve = vmalloc_max;
|
2021-05-28 03:03:58 -07:00
|
|
|
pr_warn("vmalloc area is too big, limiting to %luMiB\n",
|
2008-09-19 07:43:06 -07:00
|
|
|
vmalloc_reserve >> 20);
|
|
|
|
}
|
2010-05-22 08:20:14 -07:00
|
|
|
|
2021-05-18 04:58:34 -07:00
|
|
|
vmalloc_size = vmalloc_reserve;
|
2010-01-11 15:17:34 -07:00
|
|
|
return 0;
|
2008-09-30 11:31:44 -07:00
|
|
|
}
|
2010-01-11 15:17:34 -07:00
|
|
|
early_param("vmalloc", early_vmalloc);
|
2008-09-30 11:31:44 -07:00
|
|
|
|
2011-12-29 05:09:51 -07:00
|
|
|
phys_addr_t arm_lowmem_limit __initdata = 0;
|
2010-10-27 11:57:38 -07:00
|
|
|
|
2017-01-13 14:51:08 -07:00
|
|
|
void __init adjust_lowmem_bounds(void)
|
[ARM] prevent crashing when too much RAM installed
This patch will truncate and/or ignore memory banks if their kernel
direct mappings would (partially) overlap with the vmalloc area or
the mappings between the vmalloc area and the address space top, to
prevent crashing during early boot if there happens to be more RAM
installed than we are expecting.
Since the start of the vmalloc area is not at a fixed address (but
the vmalloc end address is, via the per-platform VMALLOC_END define),
a default area of 128M is reserved for vmalloc mappings, which can
be shrunk or enlarged by passing an appropriate vmalloc= command line
option as it is done on x86.
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
two 512M RAM banks and vmalloc=128M (the default), this patch gives:
Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
Memory: 512MB 352MB = 864MB total
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
two 256M RAM banks and vmalloc=768M, this patch gives:
Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Riku Voipio <riku.voipio@iki.fi>
2008-08-04 16:56:13 -07:00
|
|
|
{
|
2020-10-13 16:58:08 -07:00
|
|
|
phys_addr_t block_start, block_end, memblock_limit = 0;
|
|
|
|
u64 vmalloc_limit, i;
|
2017-01-13 14:51:45 -07:00
|
|
|
phys_addr_t lowmem_limit = 0;
|
[ARM] prevent crashing when too much RAM installed
This patch will truncate and/or ignore memory banks if their kernel
direct mappings would (partially) overlap with the vmalloc area or
the mappings between the vmalloc area and the address space top, to
prevent crashing during early boot if there happens to be more RAM
installed than we are expecting.
Since the start of the vmalloc area is not at a fixed address (but
the vmalloc end address is, via the per-platform VMALLOC_END define),
a default area of 128M is reserved for vmalloc mappings, which can
be shrunk or enlarged by passing an appropriate vmalloc= command line
option as it is done on x86.
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
two 512M RAM banks and vmalloc=128M (the default), this patch gives:
Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
Memory: 512MB 352MB = 864MB total
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
two 256M RAM banks and vmalloc=768M, this patch gives:
Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Riku Voipio <riku.voipio@iki.fi>
2008-08-04 16:56:13 -07:00
|
|
|
|
2016-07-28 11:38:07 -07:00
|
|
|
/*
|
|
|
|
* Let's use our own (unoptimized) equivalent of __pa() that is
|
|
|
|
* not affected by wrap-arounds when sizeof(phys_addr_t) == 4.
|
|
|
|
* The result is used as the upper bound on physical memory address
|
|
|
|
* and may itself be outside the valid range for which phys_addr_t
|
|
|
|
* and therefore __pa() is defined.
|
|
|
|
*/
|
2021-05-18 04:58:34 -07:00
|
|
|
vmalloc_limit = (u64)VMALLOC_END - vmalloc_size - VMALLOC_OFFSET -
|
2021-05-18 04:53:30 -07:00
|
|
|
PAGE_OFFSET + PHYS_OFFSET;
|
2016-07-28 11:38:07 -07:00
|
|
|
|
2019-08-30 06:27:56 -07:00
|
|
|
/*
|
|
|
|
* The first usable region must be PMD aligned. Mark its start
|
|
|
|
* as MEMBLOCK_NOMAP if it isn't
|
|
|
|
*/
|
2020-10-13 16:58:08 -07:00
|
|
|
for_each_mem_range(i, &block_start, &block_end) {
|
|
|
|
if (!IS_ALIGNED(block_start, PMD_SIZE)) {
|
|
|
|
phys_addr_t len;
|
2019-08-30 06:27:56 -07:00
|
|
|
|
2020-10-13 16:58:08 -07:00
|
|
|
len = round_up(block_start, PMD_SIZE) - block_start;
|
|
|
|
memblock_mark_nomap(block_start, len);
|
2019-08-30 06:27:56 -07:00
|
|
|
}
|
2020-10-13 16:58:08 -07:00
|
|
|
break;
|
2019-08-30 06:27:56 -07:00
|
|
|
}
|
|
|
|
|
2020-10-13 16:58:08 -07:00
|
|
|
for_each_mem_range(i, &block_start, &block_end) {
|
|
|
|
if (block_start < vmalloc_limit) {
|
2017-01-13 14:51:45 -07:00
|
|
|
if (block_end > lowmem_limit)
|
2017-01-13 14:51:08 -07:00
|
|
|
/*
|
|
|
|
* Compare as u64 to ensure vmalloc_limit does
|
|
|
|
* not get truncated. block_end should always
|
|
|
|
* fit in phys_addr_t so there should be no
|
|
|
|
* issue with assignment.
|
|
|
|
*/
|
2017-01-13 14:51:45 -07:00
|
|
|
lowmem_limit = min_t(u64,
|
2017-01-13 14:51:08 -07:00
|
|
|
vmalloc_limit,
|
|
|
|
block_end);
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
|
|
|
|
/*
|
2015-05-13 07:07:54 -07:00
|
|
|
* Find the first non-pmd-aligned page, and point
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
* memblock_limit at it. This relies on rounding the
|
2015-05-13 07:07:54 -07:00
|
|
|
* limit down to be pmd-aligned, which happens at the
|
|
|
|
* end of this function.
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
*
|
|
|
|
* With this algorithm, the start or end of almost any
|
2015-05-13 07:07:54 -07:00
|
|
|
* bank can be non-pmd-aligned. The only exception is
|
|
|
|
* that the start of the bank 0 must be section-
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
* aligned, since otherwise memory would need to be
|
|
|
|
* allocated when mapping the start of bank 0, which
|
|
|
|
* occurs before any free memory is mapped.
|
|
|
|
*/
|
|
|
|
if (!memblock_limit) {
|
2015-05-13 07:07:54 -07:00
|
|
|
if (!IS_ALIGNED(block_start, PMD_SIZE))
|
2014-04-13 14:54:58 -07:00
|
|
|
memblock_limit = block_start;
|
2015-05-13 07:07:54 -07:00
|
|
|
else if (!IS_ALIGNED(block_end, PMD_SIZE))
|
2017-01-13 14:51:45 -07:00
|
|
|
memblock_limit = lowmem_limit;
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
}
|
2009-09-27 12:55:43 -07:00
|
|
|
|
|
|
|
}
|
|
|
|
}
|
2014-04-13 14:54:58 -07:00
|
|
|
|
2017-01-13 14:51:45 -07:00
|
|
|
arm_lowmem_limit = lowmem_limit;
|
|
|
|
|
2011-12-29 05:09:51 -07:00
|
|
|
high_memory = __va(arm_lowmem_limit - 1) + 1;
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
|
2017-06-29 10:41:36 -07:00
|
|
|
if (!memblock_limit)
|
|
|
|
memblock_limit = arm_lowmem_limit;
|
|
|
|
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
/*
|
2015-05-13 07:07:54 -07:00
|
|
|
* Round the memblock limit down to a pmd size. This
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
* helps to ensure that we will allocate memory from the
|
2015-05-13 07:07:54 -07:00
|
|
|
* last full pmd, which should be mapped.
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
*/
|
2017-06-29 10:41:36 -07:00
|
|
|
memblock_limit = round_down(memblock_limit, PMD_SIZE);
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
|
2017-01-13 14:51:08 -07:00
|
|
|
if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
|
|
|
|
if (memblock_end_of_DRAM() > arm_lowmem_limit) {
|
|
|
|
phys_addr_t end = memblock_end_of_DRAM();
|
|
|
|
|
|
|
|
pr_notice("Ignoring RAM at %pa-%pa\n",
|
|
|
|
&memblock_limit, &end);
|
|
|
|
pr_notice("Consider using a HIGHMEM enabled kernel.\n");
|
|
|
|
|
|
|
|
memblock_remove(memblock_limit, end - memblock_limit);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ARM: 7785/1: mm: restrict early_alloc to section-aligned memory
When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().
At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.
This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.
The algorithm applied is:
* Default memblock_limit to arm_lowmem_limit in the absence of any other
limit; arm_lowmem_limit is the highest memory that is mapped by
map_lowmem().
* While walking the list of memblocks, if the start of a block is not
aligned, 2nd-level page tables will need to be allocated to map the
first few pages of the block. Hence, the memblock_limit must be before
the start of the block.
* Similarly, if the end of any block is not aligned, 2nd-level page
tables will need to be allocated to map the last few pages of the
block. Hence, the memblock_limit must point at the end of the block,
rounded down to section-alignment.
* The memory blocks are assumed to be sorted in address order, so the
first unaligned block start or end is used to set the limit.
With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-17 09:53:04 -07:00
|
|
|
memblock_set_current_limit(memblock_limit);
|
[ARM] prevent crashing when too much RAM installed
This patch will truncate and/or ignore memory banks if their kernel
direct mappings would (partially) overlap with the vmalloc area or
the mappings between the vmalloc area and the address space top, to
prevent crashing during early boot if there happens to be more RAM
installed than we are expecting.
Since the start of the vmalloc area is not at a fixed address (but
the vmalloc end address is, via the per-platform VMALLOC_END define),
a default area of 128M is reserved for vmalloc mappings, which can
be shrunk or enlarged by passing an appropriate vmalloc= command line
option as it is done on x86.
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
two 512M RAM banks and vmalloc=128M (the default), this patch gives:
Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
Memory: 512MB 352MB = 864MB total
On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
two 256M RAM banks and vmalloc=768M, this patch gives:
Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Riku Voipio <riku.voipio@iki.fi>
2008-08-04 16:56:13 -07:00
|
|
|
}
|
|
|
|
|
2021-05-14 03:26:38 -07:00
|
|
|
static __init void prepare_page_table(void)
|
2006-09-27 07:27:33 -07:00
|
|
|
{
|
|
|
|
unsigned long addr;
|
2010-10-27 11:57:38 -07:00
|
|
|
phys_addr_t end;
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear out all the mappings below the kernel image.
|
|
|
|
*/
|
ARM: 9015/2: Define the virtual space of KASan's shadow region
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
addressable by a 32bit architecture) out of the virtual address
space to use as shadow memory for KASan as follows:
+----+ 0xffffffff
| |
| | |-> Static kernel image (vmlinux) BSS and page table
| |/
+----+ PAGE_OFFSET
| |
| | |-> Loadable kernel modules virtual address space area
| |/
+----+ MODULES_VADDR = KASAN_SHADOW_END
| |
| | |-> The shadow area of kernel virtual address.
| |/
+----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
| | shadow address of MODULES_VADDR
| | |
| | |
| | |-> The user space area in lowmem. The kernel address
| | | sanitizer do not use this space, nor does it map it.
| | |
| | |
| | |
| | |
| |/
------ 0
0 .. TASK_SIZE is the memory that can be used by shared
userspace/kernelspace. It us used for userspace processes and for
passing parameters and memory buffers in system calls etc. We do not
need to shadow this area.
KASAN_SHADOW_START:
This value begins with the MODULE_VADDR's shadow address. It is the
start of kernel virtual space. Since we have modules to load, we need
to cover also that area with shadow memory so we can find memory
bugs in modules.
KASAN_SHADOW_END
This value is the 0x100000000's shadow address: the mapping that would
be after the end of the kernel memory at 0xffffffff. It is the end of
kernel address sanitizer shadow area. It is also the start of the
module area.
KASAN_SHADOW_OFFSET:
This value is used to map an address to the corresponding shadow
address by the following formula:
shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
As you would expect, >> 3 is equal to dividing by 8, meaning each
byte in the shadow memory covers 8 bytes of kernel memory, so one
bit shadow memory per byte of kernel memory is used.
The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
on the VMSPLIT layout of the system: the kernel and userspace can
split up lowmem in different ways according to needs, so we calculate
the shadow offset depending on this.
When kasan is enabled, the definition of TASK_SIZE is not an 8-bit
rotated constant, so we need to modify the TASK_SIZE access code in the
*.s file.
The kernel and modules may use different amounts of memory,
according to the VMSPLIT configuration, which in turn
determines the PAGE_OFFSET.
We use the following KASAN_SHADOW_OFFSETs depending on how the
virtual memory is split up:
- 0x1f000000 if we have 1G userspace / 3G kernelspace split:
- The kernel address space is 3G (0xc0000000)
- PAGE_OFFSET is then set to 0x40000000 so the kernel static
image (vmlinux) uses addresses 0x40000000 .. 0xffffffff
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x3f000000
so the modules use addresses 0x3f000000 .. 0x3fffffff
- So the addresses 0x3f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0xc1000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x18200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x26e00000, to
KASAN_SHADOW_END at 0x3effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x3f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000
KASAN_SHADOW_OFFSET = 0x1f000000
- 0x5f000000 if we have 2G userspace / 2G kernelspace split:
- The kernel space is 2G (0x80000000)
- PAGE_OFFSET is set to 0x80000000 so the kernel static
image uses 0x80000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x7f000000
so the modules use addresses 0x7f000000 .. 0x7fffffff
- So the addresses 0x7f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x81000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x10200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x6ee00000, to
KASAN_SHADOW_END at 0x7effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x7f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000
KASAN_SHADOW_OFFSET = 0x5f000000
- 0x9f000000 if we have 3G userspace / 1G kernelspace split,
and this is the default split for ARM:
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xc0000000 so the kernel static
image uses 0xc0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xbf000000
so the modules use addresses 0xbf000000 .. 0xbfffffff
- So the addresses 0xbf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x41000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x08200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xb6e00000, to
KASAN_SHADOW_END at 0xbfffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xbf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000
KASAN_SHADOW_OFFSET = 0x9f000000
- 0x8f000000 if we have 3G userspace / 1G kernelspace with
full 1 GB low memory (VMSPLIT_3G_OPT):
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xb0000000 so the kernel static
image uses 0xb0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xaf000000
so the modules use addresses 0xaf000000 .. 0xaffffff
- So the addresses 0xaf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x51000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x0a200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xa4e00000, to
KASAN_SHADOW_END at 0xaeffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xaf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000
KASAN_SHADOW_OFFSET = 0x8f000000
- The default value of 0xffffffff for KASAN_SHADOW_OFFSET
is an error value. We should always match one of the
above shadow offsets.
When we do this, TASK_SIZE will sometimes get a bit odd values
that will not fit into immediate mov assembly instructions.
To account for this, we need to rewrite some assembly using
TASK_SIZE like this:
- mov r1, #TASK_SIZE
+ ldr r1, =TASK_SIZE
or
- cmp r4, #TASK_SIZE
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
this is done to avoid the immediate #TASK_SIZE that need to
fit into a limited number of bits.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-25 15:53:46 -07:00
|
|
|
#ifdef CONFIG_KASAN
|
|
|
|
/*
|
|
|
|
* KASan's shadow memory inserts itself between the TASK_SIZE
|
|
|
|
* and MODULES_VADDR. Do not clear the KASan shadow memory mappings.
|
|
|
|
*/
|
|
|
|
for (addr = 0; addr < KASAN_SHADOW_START; addr += PMD_SIZE)
|
|
|
|
pmd_clear(pmd_off_k(addr));
|
|
|
|
/*
|
|
|
|
* Skip over the KASan shadow area. KASAN_SHADOW_END is sometimes
|
|
|
|
* equal to MODULES_VADDR and then we exit the pmd clearing. If we
|
|
|
|
* are using a thumb-compiled kernel, there there will be 8MB more
|
|
|
|
* to clear as KASan always offset to 16 MB below MODULES_VADDR.
|
|
|
|
*/
|
|
|
|
for (addr = KASAN_SHADOW_END; addr < MODULES_VADDR; addr += PMD_SIZE)
|
|
|
|
pmd_clear(pmd_off_k(addr));
|
|
|
|
#else
|
2011-08-23 06:07:23 -07:00
|
|
|
for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
|
2006-09-27 07:27:33 -07:00
|
|
|
pmd_clear(pmd_off_k(addr));
|
ARM: 9015/2: Define the virtual space of KASan's shadow region
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
addressable by a 32bit architecture) out of the virtual address
space to use as shadow memory for KASan as follows:
+----+ 0xffffffff
| |
| | |-> Static kernel image (vmlinux) BSS and page table
| |/
+----+ PAGE_OFFSET
| |
| | |-> Loadable kernel modules virtual address space area
| |/
+----+ MODULES_VADDR = KASAN_SHADOW_END
| |
| | |-> The shadow area of kernel virtual address.
| |/
+----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
| | shadow address of MODULES_VADDR
| | |
| | |
| | |-> The user space area in lowmem. The kernel address
| | | sanitizer do not use this space, nor does it map it.
| | |
| | |
| | |
| | |
| |/
------ 0
0 .. TASK_SIZE is the memory that can be used by shared
userspace/kernelspace. It us used for userspace processes and for
passing parameters and memory buffers in system calls etc. We do not
need to shadow this area.
KASAN_SHADOW_START:
This value begins with the MODULE_VADDR's shadow address. It is the
start of kernel virtual space. Since we have modules to load, we need
to cover also that area with shadow memory so we can find memory
bugs in modules.
KASAN_SHADOW_END
This value is the 0x100000000's shadow address: the mapping that would
be after the end of the kernel memory at 0xffffffff. It is the end of
kernel address sanitizer shadow area. It is also the start of the
module area.
KASAN_SHADOW_OFFSET:
This value is used to map an address to the corresponding shadow
address by the following formula:
shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
As you would expect, >> 3 is equal to dividing by 8, meaning each
byte in the shadow memory covers 8 bytes of kernel memory, so one
bit shadow memory per byte of kernel memory is used.
The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
on the VMSPLIT layout of the system: the kernel and userspace can
split up lowmem in different ways according to needs, so we calculate
the shadow offset depending on this.
When kasan is enabled, the definition of TASK_SIZE is not an 8-bit
rotated constant, so we need to modify the TASK_SIZE access code in the
*.s file.
The kernel and modules may use different amounts of memory,
according to the VMSPLIT configuration, which in turn
determines the PAGE_OFFSET.
We use the following KASAN_SHADOW_OFFSETs depending on how the
virtual memory is split up:
- 0x1f000000 if we have 1G userspace / 3G kernelspace split:
- The kernel address space is 3G (0xc0000000)
- PAGE_OFFSET is then set to 0x40000000 so the kernel static
image (vmlinux) uses addresses 0x40000000 .. 0xffffffff
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x3f000000
so the modules use addresses 0x3f000000 .. 0x3fffffff
- So the addresses 0x3f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0xc1000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x18200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x26e00000, to
KASAN_SHADOW_END at 0x3effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x3f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000
KASAN_SHADOW_OFFSET = 0x1f000000
- 0x5f000000 if we have 2G userspace / 2G kernelspace split:
- The kernel space is 2G (0x80000000)
- PAGE_OFFSET is set to 0x80000000 so the kernel static
image uses 0x80000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x7f000000
so the modules use addresses 0x7f000000 .. 0x7fffffff
- So the addresses 0x7f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x81000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x10200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x6ee00000, to
KASAN_SHADOW_END at 0x7effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x7f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000
KASAN_SHADOW_OFFSET = 0x5f000000
- 0x9f000000 if we have 3G userspace / 1G kernelspace split,
and this is the default split for ARM:
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xc0000000 so the kernel static
image uses 0xc0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xbf000000
so the modules use addresses 0xbf000000 .. 0xbfffffff
- So the addresses 0xbf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x41000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x08200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xb6e00000, to
KASAN_SHADOW_END at 0xbfffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xbf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000
KASAN_SHADOW_OFFSET = 0x9f000000
- 0x8f000000 if we have 3G userspace / 1G kernelspace with
full 1 GB low memory (VMSPLIT_3G_OPT):
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xb0000000 so the kernel static
image uses 0xb0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xaf000000
so the modules use addresses 0xaf000000 .. 0xaffffff
- So the addresses 0xaf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x51000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x0a200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xa4e00000, to
KASAN_SHADOW_END at 0xaeffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xaf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000
KASAN_SHADOW_OFFSET = 0x8f000000
- The default value of 0xffffffff for KASAN_SHADOW_OFFSET
is an error value. We should always match one of the
above shadow offsets.
When we do this, TASK_SIZE will sometimes get a bit odd values
that will not fit into immediate mov assembly instructions.
To account for this, we need to rewrite some assembly using
TASK_SIZE like this:
- mov r1, #TASK_SIZE
+ ldr r1, =TASK_SIZE
or
- cmp r4, #TASK_SIZE
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
this is done to avoid the immediate #TASK_SIZE that need to
fit into a limited number of bits.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-25 15:53:46 -07:00
|
|
|
#endif
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
#ifdef CONFIG_XIP_KERNEL
|
|
|
|
/* The XIP kernel is mapped in the module area -- skip over it */
|
2016-02-09 11:34:43 -07:00
|
|
|
addr = ((unsigned long)_exiprom + PMD_SIZE - 1) & PMD_MASK;
|
2006-09-27 07:27:33 -07:00
|
|
|
#endif
|
2011-08-23 06:07:23 -07:00
|
|
|
for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE)
|
2006-09-27 07:27:33 -07:00
|
|
|
pmd_clear(pmd_off_k(addr));
|
|
|
|
|
2010-10-27 11:57:38 -07:00
|
|
|
/*
|
|
|
|
* Find the end of the first block of lowmem.
|
|
|
|
*/
|
|
|
|
end = memblock.memory.regions[0].base + memblock.memory.regions[0].size;
|
2011-12-29 05:09:51 -07:00
|
|
|
if (end >= arm_lowmem_limit)
|
|
|
|
end = arm_lowmem_limit;
|
2010-10-27 11:57:38 -07:00
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* Clear out all the kernel space mappings, except for the first
|
2011-08-24 21:35:59 -07:00
|
|
|
* memory bank, up to the vmalloc region.
|
2006-09-27 07:27:33 -07:00
|
|
|
*/
|
2010-10-27 11:57:38 -07:00
|
|
|
for (addr = __phys_to_virt(end);
|
2011-08-24 21:35:59 -07:00
|
|
|
addr < VMALLOC_START; addr += PMD_SIZE)
|
2006-09-27 07:27:33 -07:00
|
|
|
pmd_clear(pmd_off_k(addr));
|
|
|
|
}
|
|
|
|
|
2011-11-22 10:30:29 -07:00
|
|
|
#ifdef CONFIG_ARM_LPAE
|
|
|
|
/* the first page is reserved for pgd */
|
|
|
|
#define SWAPPER_PG_DIR_SIZE (PAGE_SIZE + \
|
|
|
|
PTRS_PER_PGD * PTRS_PER_PMD * sizeof(pmd_t))
|
|
|
|
#else
|
2011-08-23 06:07:23 -07:00
|
|
|
#define SWAPPER_PG_DIR_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
|
2011-11-22 10:30:29 -07:00
|
|
|
#endif
|
2011-08-23 06:07:23 -07:00
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
2010-07-09 08:27:52 -07:00
|
|
|
* Reserve the special regions of memory
|
2006-09-27 07:27:33 -07:00
|
|
|
*/
|
2010-07-09 08:27:52 -07:00
|
|
|
void __init arm_mm_memblock_reserve(void)
|
2006-09-27 07:27:33 -07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Reserve the page tables. These are already in use,
|
|
|
|
* and can only be in node 0.
|
|
|
|
*/
|
2011-08-23 06:07:23 -07:00
|
|
|
memblock_reserve(__pa(swapper_pg_dir), SWAPPER_PG_DIR_SIZE);
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
#ifdef CONFIG_SA1111
|
|
|
|
/*
|
|
|
|
* Because of the SA1111 DMA bug, we want to preserve our
|
|
|
|
* precious DMA-able memory...
|
|
|
|
*/
|
2010-07-09 08:27:52 -07:00
|
|
|
memblock_reserve(PHYS_OFFSET, __pa(swapper_pg_dir) - PHYS_OFFSET);
|
2006-09-27 07:27:33 -07:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-08-24 21:35:59 -07:00
|
|
|
* Set up the device mappings. Since we clear out the page tables for all
|
2015-08-12 16:01:52 -07:00
|
|
|
* mappings above VMALLOC_START, except early fixmap, we might remove debug
|
|
|
|
* device mappings. This means earlycon can be used to debug this function
|
|
|
|
* Any other function or debugging method which may touch any device _will_
|
|
|
|
* crash the kernel.
|
2006-09-27 07:27:33 -07:00
|
|
|
*/
|
2013-07-26 06:55:59 -07:00
|
|
|
static void __init devicemaps_init(const struct machine_desc *mdesc)
|
2006-09-27 07:27:33 -07:00
|
|
|
{
|
|
|
|
struct map_desc map;
|
|
|
|
unsigned long addr;
|
2012-01-18 08:32:49 -07:00
|
|
|
void *vectors;
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate the vector page early.
|
|
|
|
*/
|
2013-07-04 03:40:32 -07:00
|
|
|
vectors = early_alloc(PAGE_SIZE * 2);
|
2012-01-18 08:32:49 -07:00
|
|
|
|
|
|
|
early_trap_init(vectors);
|
2006-09-27 07:27:33 -07:00
|
|
|
|
2015-08-12 16:01:52 -07:00
|
|
|
/*
|
|
|
|
* Clear page table except top pmd used by early fixmaps
|
|
|
|
*/
|
|
|
|
for (addr = VMALLOC_START; addr < (FIXADDR_TOP & PMD_MASK); addr += PMD_SIZE)
|
2006-09-27 07:27:33 -07:00
|
|
|
pmd_clear(pmd_off_k(addr));
|
|
|
|
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
if (__atags_pointer) {
|
|
|
|
/* create a read-only mapping of the device tree */
|
|
|
|
map.pfn = __phys_to_pfn(__atags_pointer & SECTION_MASK);
|
|
|
|
map.virtual = FDT_FIXED_BASE;
|
|
|
|
map.length = FDT_FIXED_SIZE;
|
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
|<---------FDT_FIXED_SIZE------>|
| |
-------------------------------
| <non-fdt> | <fdt> | <non-fdt> |
-------------------------------
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
Here's an example:
list_del corruption. prev->next should be c0ecbf74, but was c08410dc
kernel BUG at lib/list_debug.c:53!
... ...
PC is at __list_del_entry_valid+0x58/0x98
LR is at __list_del_entry_valid+0x58/0x98
psr: 60000093
sp : c0ecbf30 ip : 00000000 fp : 00000001
r10: c08410d0 r9 : 00000001 r8 : c0825e0c
r7 : 20000013 r6 : c08410d0 r5 : c0ecbf74 r4 : c0ecbf74
r3 : c0825d08 r2 : 00000000 r1 : df7ce6f4 r0 : 00000044
... ...
Stack: (0xc0ecbf30 to 0xc0ecc000)
bf20: c0ecbf74 c0164fd0 c0ecbf70 c0165170
bf40: c0eca000 c0840c00 c0840c00 c0824500 c0825e0c c0189bbc c088f404 60000013
bf60: 60000013 c0e85100 000004ec 00000000 c0ebcdc0 c0ecbf74 c0ecbf74 c0825d08
... ... < next prev >
(__list_del_entry_valid) from (__list_del_entry+0xc/0x20)
(__list_del_entry) from (finish_swait+0x60/0x7c)
(finish_swait) from (rcu_gp_kthread+0x560/0xa20)
(rcu_gp_kthread) from (kthread+0x14c/0x15c)
(kthread) from (ret_from_fork+0x14/0x24)
The faulty list node to be deleted is a local variable, its address is
c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-06-13 07:05:41 -07:00
|
|
|
map.type = MT_MEMORY_RO;
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
create_mapping(&map);
|
|
|
|
}
|
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* Map the cache flushing regions.
|
|
|
|
*/
|
|
|
|
#ifdef FLUSH_BASE
|
|
|
|
map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS);
|
|
|
|
map.virtual = FLUSH_BASE;
|
|
|
|
map.length = SZ_1M;
|
|
|
|
map.type = MT_CACHECLEAN;
|
|
|
|
create_mapping(&map);
|
|
|
|
#endif
|
|
|
|
#ifdef FLUSH_BASE_MINICACHE
|
|
|
|
map.pfn = __phys_to_pfn(FLUSH_BASE_PHYS + SZ_1M);
|
|
|
|
map.virtual = FLUSH_BASE_MINICACHE;
|
|
|
|
map.length = SZ_1M;
|
|
|
|
map.type = MT_MINICLEAN;
|
|
|
|
create_mapping(&map);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a mapping for the machine vectors at the high-vectors
|
|
|
|
* location (0xffff0000). If we aren't using high-vectors, also
|
|
|
|
* create a mapping at the low-vectors virtual address.
|
|
|
|
*/
|
2012-01-18 08:32:49 -07:00
|
|
|
map.pfn = __phys_to_pfn(virt_to_phys(vectors));
|
2006-09-27 07:27:33 -07:00
|
|
|
map.virtual = 0xffff0000;
|
|
|
|
map.length = PAGE_SIZE;
|
2013-07-31 13:58:56 -07:00
|
|
|
#ifdef CONFIG_KUSER_HELPERS
|
2006-09-27 07:27:33 -07:00
|
|
|
map.type = MT_HIGH_VECTORS;
|
2013-07-31 13:58:56 -07:00
|
|
|
#else
|
|
|
|
map.type = MT_LOW_VECTORS;
|
|
|
|
#endif
|
2006-09-27 07:27:33 -07:00
|
|
|
create_mapping(&map);
|
|
|
|
|
|
|
|
if (!vectors_high()) {
|
|
|
|
map.virtual = 0;
|
2013-07-04 03:40:32 -07:00
|
|
|
map.length = PAGE_SIZE * 2;
|
2006-09-27 07:27:33 -07:00
|
|
|
map.type = MT_LOW_VECTORS;
|
|
|
|
create_mapping(&map);
|
|
|
|
}
|
|
|
|
|
2013-07-04 03:40:32 -07:00
|
|
|
/* Now create a kernel read-only mapping */
|
|
|
|
map.pfn += 1;
|
|
|
|
map.virtual = 0xffff0000 + PAGE_SIZE;
|
|
|
|
map.length = PAGE_SIZE;
|
|
|
|
map.type = MT_LOW_VECTORS;
|
|
|
|
create_mapping(&map);
|
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* Ask the machine support to map in the statically mapped devices.
|
|
|
|
*/
|
|
|
|
if (mdesc->map_io)
|
|
|
|
mdesc->map_io();
|
2013-04-18 12:52:23 -07:00
|
|
|
else
|
|
|
|
debug_ll_io_init();
|
2012-06-27 09:28:57 -07:00
|
|
|
fill_pmd_gaps();
|
2006-09-27 07:27:33 -07:00
|
|
|
|
2012-02-29 17:10:58 -07:00
|
|
|
/* Reserve fixed i/o space in VMALLOC region */
|
|
|
|
pci_reserve_io();
|
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* Finally flush the caches and tlb to ensure that we're in a
|
|
|
|
* consistent state wrt the writebuffer. This also ensures that
|
|
|
|
* any write-allocated cache lines in the vector page are written
|
|
|
|
* back. After this point, we can start to touch devices again.
|
|
|
|
*/
|
|
|
|
local_flush_tlb_all();
|
|
|
|
flush_cache_all();
|
2015-08-25 05:52:09 -07:00
|
|
|
|
|
|
|
/* Enable asynchronous aborts */
|
2015-10-19 05:38:09 -07:00
|
|
|
early_abt_enable();
|
2006-09-27 07:27:33 -07:00
|
|
|
}
|
|
|
|
|
2008-09-15 13:44:55 -07:00
|
|
|
static void __init kmap_init(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_HIGHMEM
|
2010-07-01 10:33:29 -07:00
|
|
|
pkmap_page_table = early_pte_alloc(pmd_off_k(PKMAP_BASE),
|
|
|
|
PKMAP_BASE, _PAGE_KERNEL_TABLE);
|
2008-09-15 13:44:55 -07:00
|
|
|
#endif
|
2014-07-02 00:01:15 -07:00
|
|
|
|
|
|
|
early_pte_alloc(pmd_off_k(FIXADDR_START), FIXADDR_START,
|
|
|
|
_PAGE_KERNEL_TABLE);
|
2008-09-15 13:44:55 -07:00
|
|
|
}
|
|
|
|
|
2010-03-25 11:56:05 -07:00
|
|
|
static void __init map_lowmem(void)
|
|
|
|
{
|
2020-10-13 16:58:08 -07:00
|
|
|
phys_addr_t start, end;
|
|
|
|
u64 i;
|
2010-03-25 11:56:05 -07:00
|
|
|
|
|
|
|
/* Map all the lowmem memory banks. */
|
2020-10-13 16:58:08 -07:00
|
|
|
for_each_mem_range(i, &start, &end) {
|
2010-10-27 11:57:38 -07:00
|
|
|
struct map_desc map;
|
|
|
|
|
2021-06-03 01:52:02 -07:00
|
|
|
pr_debug("map lowmem start: 0x%08llx, end: 0x%08llx\n",
|
|
|
|
(long long)start, (long long)end);
|
2011-12-29 05:09:51 -07:00
|
|
|
if (end > arm_lowmem_limit)
|
|
|
|
end = arm_lowmem_limit;
|
2010-10-27 11:57:38 -07:00
|
|
|
if (start >= end)
|
|
|
|
break;
|
|
|
|
|
2021-06-03 01:52:02 -07:00
|
|
|
/*
|
|
|
|
* If our kernel image is in the VMALLOC area we need to remove
|
|
|
|
* the kernel physical memory from lowmem since the kernel will
|
|
|
|
* be mapped separately.
|
|
|
|
*
|
|
|
|
* The kernel will typically be at the very start of lowmem,
|
|
|
|
* but any placement relative to memory ranges is possible.
|
|
|
|
*
|
|
|
|
* If the memblock contains the kernel, we have to chisel out
|
|
|
|
* the kernel memory from it and map each part separately. We
|
|
|
|
* get 6 different theoretical cases:
|
|
|
|
*
|
|
|
|
* +--------+ +--------+
|
|
|
|
* +-- start --+ +--------+ | Kernel | | Kernel |
|
|
|
|
* | | | Kernel | | case 2 | | case 5 |
|
|
|
|
* | | | case 1 | +--------+ | | +--------+
|
|
|
|
* | Memory | +--------+ | | | Kernel |
|
|
|
|
* | range | +--------+ | | | case 6 |
|
|
|
|
* | | | Kernel | +--------+ | | +--------+
|
|
|
|
* | | | case 3 | | Kernel | | |
|
|
|
|
* +-- end ----+ +--------+ | case 4 | | |
|
|
|
|
* +--------+ +--------+
|
|
|
|
*/
|
2010-03-25 11:56:05 -07:00
|
|
|
|
2021-06-03 01:52:02 -07:00
|
|
|
/* Case 5: kernel covers range, don't map anything, should be rare */
|
|
|
|
if ((start > kernel_sec_start) && (end < kernel_sec_end))
|
|
|
|
break;
|
2014-04-03 17:28:11 -07:00
|
|
|
|
2021-06-03 01:52:02 -07:00
|
|
|
/* Cases where the kernel is starting inside the range */
|
|
|
|
if ((kernel_sec_start >= start) && (kernel_sec_start <= end)) {
|
|
|
|
/* Case 6: kernel is embedded in the range, we need two mappings */
|
|
|
|
if ((start < kernel_sec_start) && (end > kernel_sec_end)) {
|
|
|
|
/* Map memory below the kernel */
|
2013-10-24 00:12:39 -07:00
|
|
|
map.pfn = __phys_to_pfn(start);
|
|
|
|
map.virtual = __phys_to_virt(start);
|
2021-06-03 01:52:02 -07:00
|
|
|
map.length = kernel_sec_start - start;
|
2013-10-24 00:12:39 -07:00
|
|
|
map.type = MT_MEMORY_RW;
|
|
|
|
create_mapping(&map);
|
2021-06-03 01:52:02 -07:00
|
|
|
/* Map memory above the kernel */
|
|
|
|
map.pfn = __phys_to_pfn(kernel_sec_end);
|
|
|
|
map.virtual = __phys_to_virt(kernel_sec_end);
|
|
|
|
map.length = end - kernel_sec_end;
|
2013-10-24 00:12:39 -07:00
|
|
|
map.type = MT_MEMORY_RW;
|
|
|
|
create_mapping(&map);
|
2021-06-03 01:52:02 -07:00
|
|
|
break;
|
2013-10-24 00:12:39 -07:00
|
|
|
}
|
2021-06-03 01:52:02 -07:00
|
|
|
/* Case 1: kernel and range start at the same address, should be common */
|
|
|
|
if (kernel_sec_start == start)
|
|
|
|
start = kernel_sec_end;
|
|
|
|
/* Case 3: kernel and range end at the same address, should be rare */
|
|
|
|
if (kernel_sec_end == end)
|
|
|
|
end = kernel_sec_start;
|
|
|
|
} else if ((kernel_sec_start < start) && (kernel_sec_end > start) && (kernel_sec_end < end)) {
|
|
|
|
/* Case 2: kernel ends inside range, starts below it */
|
|
|
|
start = kernel_sec_end;
|
|
|
|
} else if ((kernel_sec_start > start) && (kernel_sec_start < end) && (kernel_sec_end > end)) {
|
|
|
|
/* Case 4: kernel starts inside range, ends above it */
|
|
|
|
end = kernel_sec_start;
|
2013-10-24 00:12:39 -07:00
|
|
|
}
|
2021-06-03 01:52:02 -07:00
|
|
|
map.pfn = __phys_to_pfn(start);
|
|
|
|
map.virtual = __phys_to_virt(start);
|
|
|
|
map.length = end - start;
|
|
|
|
map.type = MT_MEMORY_RW;
|
|
|
|
create_mapping(&map);
|
2010-03-25 11:56:05 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-03 01:52:02 -07:00
|
|
|
static void __init map_kernel(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We use the well known kernel section start and end and split the area in the
|
|
|
|
* middle like this:
|
|
|
|
* . .
|
|
|
|
* | RW memory |
|
|
|
|
* +----------------+ kernel_x_start
|
|
|
|
* | Executable |
|
|
|
|
* | kernel memory |
|
|
|
|
* +----------------+ kernel_x_end / kernel_nx_start
|
|
|
|
* | Non-executable |
|
|
|
|
* | kernel memory |
|
|
|
|
* +----------------+ kernel_nx_end
|
|
|
|
* | RW memory |
|
|
|
|
* . .
|
|
|
|
*
|
|
|
|
* Notice that we are dealing with section sized mappings here so all of this
|
|
|
|
* will be bumped to the closest section boundary. This means that some of the
|
|
|
|
* non-executable part of the kernel memory is actually mapped as executable.
|
|
|
|
* This will only persist until we turn on proper memory management later on
|
|
|
|
* and we remap the whole kernel with page granularity.
|
|
|
|
*/
|
2024-09-17 22:57:11 -07:00
|
|
|
#ifdef CONFIG_XIP_KERNEL
|
|
|
|
phys_addr_t kernel_nx_start = kernel_sec_start;
|
|
|
|
#else
|
2021-06-03 01:52:02 -07:00
|
|
|
phys_addr_t kernel_x_start = kernel_sec_start;
|
|
|
|
phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
|
|
|
|
phys_addr_t kernel_nx_start = kernel_x_end;
|
2024-09-17 22:57:11 -07:00
|
|
|
#endif
|
2021-06-03 01:52:02 -07:00
|
|
|
phys_addr_t kernel_nx_end = kernel_sec_end;
|
|
|
|
struct map_desc map;
|
|
|
|
|
2024-09-17 22:57:11 -07:00
|
|
|
/*
|
|
|
|
* Map the kernel if it is XIP.
|
|
|
|
* It is always first in the modulearea.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_XIP_KERNEL
|
|
|
|
map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK);
|
|
|
|
map.virtual = MODULES_VADDR;
|
|
|
|
map.length = ((unsigned long)_exiprom - map.virtual + ~SECTION_MASK) & SECTION_MASK;
|
|
|
|
map.type = MT_ROM;
|
|
|
|
create_mapping(&map);
|
|
|
|
#else
|
2021-06-03 01:52:02 -07:00
|
|
|
map.pfn = __phys_to_pfn(kernel_x_start);
|
|
|
|
map.virtual = __phys_to_virt(kernel_x_start);
|
|
|
|
map.length = kernel_x_end - kernel_x_start;
|
|
|
|
map.type = MT_MEMORY_RWX;
|
|
|
|
create_mapping(&map);
|
|
|
|
|
|
|
|
/* If the nx part is small it may end up covered by the tail of the RWX section */
|
|
|
|
if (kernel_x_end == kernel_nx_end)
|
|
|
|
return;
|
2024-09-17 22:57:11 -07:00
|
|
|
#endif
|
2021-06-03 01:52:02 -07:00
|
|
|
map.pfn = __phys_to_pfn(kernel_nx_start);
|
|
|
|
map.virtual = __phys_to_virt(kernel_nx_start);
|
|
|
|
map.length = kernel_nx_end - kernel_nx_start;
|
|
|
|
map.type = MT_MEMORY_RW;
|
|
|
|
create_mapping(&map);
|
|
|
|
}
|
|
|
|
|
2015-04-04 08:58:38 -07:00
|
|
|
#ifdef CONFIG_ARM_PV_FIXUP
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
typedef void pgtables_remap(long long offset, unsigned long pgd);
|
2015-04-04 08:58:38 -07:00
|
|
|
pgtables_remap lpae_pgtables_remap_asm;
|
|
|
|
|
2013-07-31 09:44:46 -07:00
|
|
|
/*
|
|
|
|
* early_paging_init() recreates boot time page table setup, allowing machines
|
|
|
|
* to switch over to a high (>4G) address space on LPAE systems
|
|
|
|
*/
|
2017-04-10 03:13:59 -07:00
|
|
|
static void __init early_paging_init(const struct machine_desc *mdesc)
|
2013-07-31 09:44:46 -07:00
|
|
|
{
|
2015-04-04 08:58:38 -07:00
|
|
|
pgtables_remap *lpae_pgtables_remap;
|
|
|
|
unsigned long pa_pgd;
|
2024-07-02 01:56:54 -07:00
|
|
|
u32 cr, ttbcr, tmp;
|
2015-04-04 01:53:38 -07:00
|
|
|
long long offset;
|
2013-07-31 09:44:46 -07:00
|
|
|
|
2015-04-04 02:01:10 -07:00
|
|
|
if (!mdesc->pv_fixup)
|
2013-07-31 09:44:46 -07:00
|
|
|
return;
|
|
|
|
|
2015-04-04 02:01:10 -07:00
|
|
|
offset = mdesc->pv_fixup();
|
2015-04-04 01:53:38 -07:00
|
|
|
if (offset == 0)
|
|
|
|
return;
|
2013-07-31 09:44:46 -07:00
|
|
|
|
2021-08-09 04:57:19 -07:00
|
|
|
/*
|
|
|
|
* Offset the kernel section physical offsets so that the kernel
|
|
|
|
* mapping will work out later on.
|
|
|
|
*/
|
|
|
|
kernel_sec_start += offset;
|
|
|
|
kernel_sec_end += offset;
|
|
|
|
|
2015-04-04 08:58:38 -07:00
|
|
|
/*
|
|
|
|
* Get the address of the remap function in the 1:1 identity
|
|
|
|
* mapping setup by the early page table assembly code. We
|
|
|
|
* must get this prior to the pv update. The following barrier
|
|
|
|
* ensures that this is complete before we fixup any P:V offsets.
|
|
|
|
*/
|
|
|
|
lpae_pgtables_remap = (pgtables_remap *)(unsigned long)__pa(lpae_pgtables_remap_asm);
|
|
|
|
pa_pgd = __pa(swapper_pg_dir);
|
|
|
|
barrier();
|
2013-07-31 09:44:46 -07:00
|
|
|
|
2015-04-04 02:25:28 -07:00
|
|
|
pr_info("Switching physical address space to 0x%08llx\n",
|
|
|
|
(u64)PHYS_OFFSET + offset);
|
2013-07-31 09:44:46 -07:00
|
|
|
|
2015-04-04 01:53:38 -07:00
|
|
|
/* Re-set the phys pfn offset, and the pv offset */
|
|
|
|
__pv_offset += offset;
|
|
|
|
__pv_phys_pfn_offset += PFN_DOWN(offset);
|
2013-07-31 09:44:46 -07:00
|
|
|
|
|
|
|
/* Run the patch stub to update the constants */
|
|
|
|
fixup_pv_table(&__pv_table_begin,
|
|
|
|
(&__pv_table_end - &__pv_table_begin) << 2);
|
|
|
|
|
|
|
|
/*
|
2015-04-04 08:58:38 -07:00
|
|
|
* We changing not only the virtual to physical mapping, but also
|
|
|
|
* the physical addresses used to access memory. We need to flush
|
|
|
|
* all levels of cache in the system with caching disabled to
|
|
|
|
* ensure that all data is written back, and nothing is prefetched
|
|
|
|
* into the caches. We also need to prevent the TLB walkers
|
|
|
|
* allocating into the caches too. Note that this is ARMv7 LPAE
|
|
|
|
* specific.
|
2014-07-29 01:27:13 -07:00
|
|
|
*/
|
2015-04-04 08:58:38 -07:00
|
|
|
cr = get_cr();
|
|
|
|
set_cr(cr & ~(CR_I | CR_C));
|
2024-03-25 00:28:50 -07:00
|
|
|
ttbcr = cpu_get_ttbcr();
|
2024-07-02 01:56:54 -07:00
|
|
|
/* Disable all kind of caching of the translation table */
|
|
|
|
tmp = ttbcr & ~(TTBCR_ORGN0_MASK | TTBCR_IRGN0_MASK);
|
|
|
|
cpu_set_ttbcr(tmp);
|
2013-07-31 09:44:46 -07:00
|
|
|
flush_cache_all();
|
2014-07-29 01:27:13 -07:00
|
|
|
|
|
|
|
/*
|
2015-04-04 08:58:38 -07:00
|
|
|
* Fixup the page tables - this must be in the idmap region as
|
|
|
|
* we need to disable the MMU to do this safely, and hence it
|
|
|
|
* needs to be assembly. It's fairly simple, as we're using the
|
|
|
|
* temporary tables setup by the initial assembly code.
|
2014-07-29 01:27:13 -07:00
|
|
|
*/
|
ARM: 9012/1: move device tree mapping out of linear region
On ARM, setting up the linear region is tricky, given the constraints
around placement and alignment of the memblocks, and how the kernel
itself as well as the DT are placed in physical memory.
Let's simplify matters a bit, by moving the device tree mapping to the
top of the address space, right between the end of the vmalloc region
and the start of the the fixmap region, and create a read-only mapping
for it that is independent of the size of the linear region, and how it
is organized.
Since this region was formerly used as a guard region, which will now be
populated fully on LPAE builds by this read-only mapping (which will
still be able to function as a guard region for stray writes), bump the
start of the [underutilized] fixmap region by 512 KB as well, to ensure
that there is always a proper guard region here. Doing so still leaves
ample room for the fixmap space, even with NR_CPUS set to its maximum
value of 32.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-11 02:21:37 -07:00
|
|
|
lpae_pgtables_remap(offset, pa_pgd);
|
2014-07-29 01:27:13 -07:00
|
|
|
|
2015-04-04 08:58:38 -07:00
|
|
|
/* Re-enable the caches and cacheable TLB walks */
|
2024-03-25 00:28:50 -07:00
|
|
|
cpu_set_ttbcr(ttbcr);
|
2015-04-04 08:58:38 -07:00
|
|
|
set_cr(cr);
|
2013-07-31 09:44:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
2017-04-10 03:13:59 -07:00
|
|
|
static void __init early_paging_init(const struct machine_desc *mdesc)
|
2013-07-31 09:44:46 -07:00
|
|
|
{
|
2015-04-04 01:53:38 -07:00
|
|
|
long long offset;
|
|
|
|
|
2015-04-04 02:01:10 -07:00
|
|
|
if (!mdesc->pv_fixup)
|
2015-04-04 01:53:38 -07:00
|
|
|
return;
|
|
|
|
|
2015-04-04 02:01:10 -07:00
|
|
|
offset = mdesc->pv_fixup();
|
2015-04-04 01:53:38 -07:00
|
|
|
if (offset == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pr_crit("Physical address space modification is only to support Keystone2.\n");
|
|
|
|
pr_crit("Please enable ARM_LPAE and ARM_PATCH_PHYS_VIRT support to use this\n");
|
|
|
|
pr_crit("feature. Your kernel may crash now, have a good day.\n");
|
|
|
|
add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
|
2013-07-31 09:44:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2015-08-12 16:01:52 -07:00
|
|
|
static void __init early_fixmap_shutdown(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long va = fix_to_virt(__end_of_permanent_fixed_addresses - 1);
|
|
|
|
|
|
|
|
pte_offset_fixmap = pte_offset_late_fixmap;
|
|
|
|
pmd_clear(fixmap_pmd(va));
|
|
|
|
local_flush_tlb_kernel_page(va);
|
|
|
|
|
|
|
|
for (i = 0; i < __end_of_permanent_fixed_addresses; i++) {
|
|
|
|
pte_t *pte;
|
|
|
|
struct map_desc map;
|
|
|
|
|
|
|
|
map.virtual = fix_to_virt(i);
|
|
|
|
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), map.virtual);
|
|
|
|
|
|
|
|
/* Only i/o device mappings are supported ATM */
|
|
|
|
if (pte_none(*pte) ||
|
|
|
|
(pte_val(*pte) & L_PTE_MT_MASK) != L_PTE_MT_DEV_SHARED)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
map.pfn = pte_pfn(*pte);
|
|
|
|
map.type = MT_DEVICE;
|
|
|
|
map.length = PAGE_SIZE;
|
|
|
|
|
|
|
|
create_mapping(&map);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
/*
|
|
|
|
* paging_init() sets up the page tables, initialises the zone memory
|
|
|
|
* maps, and sets up the zero page, bad page and bad page tables.
|
|
|
|
*/
|
2013-07-26 06:55:59 -07:00
|
|
|
void __init paging_init(const struct machine_desc *mdesc)
|
2006-09-27 07:27:33 -07:00
|
|
|
{
|
|
|
|
void *zero_page;
|
|
|
|
|
2024-09-17 22:57:11 -07:00
|
|
|
#ifdef CONFIG_XIP_KERNEL
|
|
|
|
/* Store the kernel RW RAM region start/end in these variables */
|
|
|
|
kernel_sec_start = CONFIG_PHYS_OFFSET & SECTION_MASK;
|
|
|
|
kernel_sec_end = round_up(__pa(_end), SECTION_SIZE);
|
|
|
|
#endif
|
2021-08-09 04:57:19 -07:00
|
|
|
pr_debug("physical kernel sections: 0x%08llx-0x%08llx\n",
|
2021-06-03 01:52:02 -07:00
|
|
|
kernel_sec_start, kernel_sec_end);
|
|
|
|
|
2008-10-06 10:24:40 -07:00
|
|
|
prepare_page_table();
|
2010-03-25 11:56:05 -07:00
|
|
|
map_lowmem();
|
2015-06-24 17:04:20 -07:00
|
|
|
memblock_set_current_limit(arm_lowmem_limit);
|
2021-06-03 01:52:02 -07:00
|
|
|
pr_debug("lowmem limit is %08llx\n", (long long)arm_lowmem_limit);
|
|
|
|
/*
|
|
|
|
* After this point early_alloc(), i.e. the memblock allocator, can
|
|
|
|
* be used
|
|
|
|
*/
|
|
|
|
map_kernel();
|
2011-12-29 05:09:51 -07:00
|
|
|
dma_contiguous_remap();
|
2015-08-12 16:01:52 -07:00
|
|
|
early_fixmap_shutdown();
|
2006-09-27 07:27:33 -07:00
|
|
|
devicemaps_init(mdesc);
|
2008-09-15 13:44:55 -07:00
|
|
|
kmap_init();
|
2013-04-04 19:16:51 -07:00
|
|
|
tcm_init();
|
2006-09-27 07:27:33 -07:00
|
|
|
|
|
|
|
top_pmd = pmd_off_k(0xffff0000);
|
|
|
|
|
2010-03-25 10:02:59 -07:00
|
|
|
/* allocate the zero page. */
|
|
|
|
zero_page = early_alloc(PAGE_SIZE);
|
2010-07-09 08:27:52 -07:00
|
|
|
|
2010-05-22 11:47:18 -07:00
|
|
|
bootmem_init();
|
2010-07-09 08:27:52 -07:00
|
|
|
|
2006-09-27 07:27:33 -07:00
|
|
|
empty_zero_page = virt_to_page(zero_page);
|
2023-08-02 08:13:37 -07:00
|
|
|
__flush_dcache_folio(NULL, page_folio(empty_zero_page));
|
2006-09-27 07:27:33 -07:00
|
|
|
}
|
2017-04-10 03:13:59 -07:00
|
|
|
|
|
|
|
void __init early_mm_init(const struct machine_desc *mdesc)
|
|
|
|
{
|
|
|
|
build_mem_type_table();
|
|
|
|
early_paging_init(mdesc);
|
|
|
|
}
|
2020-04-10 14:33:13 -07:00
|
|
|
|
2023-08-02 08:13:37 -07:00
|
|
|
void set_ptes(struct mm_struct *mm, unsigned long addr,
|
|
|
|
pte_t *ptep, pte_t pteval, unsigned int nr)
|
2020-04-10 14:33:13 -07:00
|
|
|
{
|
|
|
|
unsigned long ext = 0;
|
|
|
|
|
|
|
|
if (addr < TASK_SIZE && pte_valid_user(pteval)) {
|
|
|
|
if (!pte_special(pteval))
|
|
|
|
__sync_icache_dcache(pteval);
|
|
|
|
ext |= PTE_EXT_NG;
|
|
|
|
}
|
|
|
|
|
2023-08-02 08:13:37 -07:00
|
|
|
for (;;) {
|
|
|
|
set_pte_ext(ptep, pteval, ext);
|
|
|
|
if (--nr == 0)
|
|
|
|
break;
|
|
|
|
ptep++;
|
2024-01-29 05:46:43 -07:00
|
|
|
pteval = pte_next_pfn(pteval);
|
2023-08-02 08:13:37 -07:00
|
|
|
}
|
2020-04-10 14:33:13 -07:00
|
|
|
}
|