2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* PowerPC64 port by Mike Corrigan and Dave Engebretsen
|
|
|
|
* {mikejc|engebret}@us.ibm.com
|
|
|
|
*
|
|
|
|
* Copyright (c) 2000 Mike Corrigan <mikejc@us.ibm.com>
|
|
|
|
*
|
|
|
|
* SMP scalability work:
|
|
|
|
* Copyright (C) 2001 Anton Blanchard <anton@au.ibm.com>, IBM
|
|
|
|
*
|
|
|
|
* Module name: htab.c
|
|
|
|
*
|
|
|
|
* Description:
|
|
|
|
* PowerPC Hashed Page Table functions
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#undef DEBUG
|
2005-11-07 07:06:55 +07:00
|
|
|
#undef DEBUG_LOW
|
2005-04-17 05:20:36 +07:00
|
|
|
|
powerpc/mm/hash: Add pr_fmt() to hash_utils64.c
Make the printks look a bit nicer by adding a prefix.
Radix config now do
radix-mmu: Page sizes from device-tree:
radix-mmu: Page size shift = 12 AP=0x0
radix-mmu: Page size shift = 16 AP=0x5
radix-mmu: Page size shift = 21 AP=0x1
radix-mmu: Page size shift = 30 AP=0x2
This patch update hash config to do similar dmesg output. With the patch we have
hash-mmu: Page sizes from device-tree:
hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=7
hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=56
hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=8
hash-mmu: base_shift=20: shift=20, sllp=0x0111, avpnm=0x00000000, tlbiel=0, penc=2
hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff, tlbiel=0, penc=3
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-16 14:01:40 +07:00
|
|
|
#define pr_fmt(fmt) "hash-mmu: " fmt
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/errno.h>
|
2017-02-04 06:16:44 +07:00
|
|
|
#include <linux/sched/mm.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/proc_fs.h>
|
|
|
|
#include <linux/stat.h>
|
|
|
|
#include <linux/sysctl.h>
|
2011-05-27 21:46:24 +07:00
|
|
|
#include <linux/export.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/ctype.h>
|
|
|
|
#include <linux/cache.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/signal.h>
|
2010-07-12 11:36:09 +07:00
|
|
|
#include <linux/memblock.h>
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
#include <linux/context_tracking.h>
|
2016-07-05 12:03:53 +07:00
|
|
|
#include <linux/libfdt.h>
|
2018-01-19 08:50:24 +07:00
|
|
|
#include <linux/pkeys.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2017-02-10 08:04:56 +07:00
|
|
|
#include <asm/debugfs.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/pgtable.h>
|
|
|
|
#include <asm/mmu.h>
|
|
|
|
#include <asm/mmu_context.h>
|
|
|
|
#include <asm/page.h>
|
|
|
|
#include <asm/types.h>
|
2016-12-25 02:46:01 +07:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <asm/machdep.h>
|
2008-02-14 07:56:49 +07:00
|
|
|
#include <asm/prom.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <asm/tlbflush.h>
|
|
|
|
#include <asm/io.h>
|
|
|
|
#include <asm/eeh.h>
|
|
|
|
#include <asm/tlb.h>
|
|
|
|
#include <asm/cacheflush.h>
|
|
|
|
#include <asm/cputable.h>
|
|
|
|
#include <asm/sections.h>
|
2014-10-08 15:54:52 +07:00
|
|
|
#include <asm/copro.h>
|
2007-10-30 02:24:19 +07:00
|
|
|
#include <asm/udbg.h>
|
2011-04-05 06:56:18 +07:00
|
|
|
#include <asm/code-patching.h>
|
2012-02-20 09:15:03 +07:00
|
|
|
#include <asm/fadump.h>
|
2012-03-16 01:18:00 +07:00
|
|
|
#include <asm/firmware.h>
|
2013-02-13 23:21:40 +07:00
|
|
|
#include <asm/tm.h>
|
powerpc/mm: Add trace point for tracking hash pte fault
This enables us to understand how many hash fault we are taking
when running benchmarks.
For ex:
-bash-4.2# ./perf stat -e powerpc:hash_fault -e page-faults /tmp/ebizzy.ppc64 -S 30 -P -n 1000
...
Performance counter stats for '/tmp/ebizzy.ppc64 -S 30 -P -n 1000':
1,10,04,075 powerpc:hash_fault
1,10,03,429 page-faults
30.865978991 seconds time elapsed
NOTE:
The impact of the tracepoint was not noticeable when running test. It was
within the run-time variance of the test. For ex:
without-patch:
--------------
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.089 M/sec
7.236562 task-clock (msec) # 0.928 CPUs utilized
2,179,213 stalled-cycles-frontend # 0.00% frontend cycles idle
17,174,367 stalled-cycles-backend # 0.00% backend cycles idle
0 context-switches # 0.000 K/sec
0.007794658 seconds time elapsed
And with-patch:
---------------
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.089 M/sec
7.233746 task-clock (msec) # 0.921 CPUs utilized
0 context-switches # 0.000 K/sec
0.007854876 seconds time elapsed
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.087 M/sec
649 powerpc:hash_fault # 0.087 M/sec
7.430376 task-clock (msec) # 0.938 CPUs utilized
2,347,174 stalled-cycles-frontend # 0.00% frontend cycles idle
17,524,282 stalled-cycles-backend # 0.00% backend cycles idle
0 context-switches # 0.000 K/sec
0.007920284 seconds time elapsed
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-04-14 14:35:57 +07:00
|
|
|
#include <asm/trace.h>
|
2016-07-05 12:03:51 +07:00
|
|
|
#include <asm/ps3.h>
|
2017-07-27 13:24:53 +07:00
|
|
|
#include <asm/pte-walk.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
#define DBG(fmt...) udbg_printf(fmt)
|
|
|
|
#else
|
|
|
|
#define DBG(fmt...)
|
|
|
|
#endif
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
#ifdef DEBUG_LOW
|
|
|
|
#define DBG_LOW(fmt...) udbg_printf(fmt)
|
|
|
|
#else
|
|
|
|
#define DBG_LOW(fmt...)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define KB (1024)
|
|
|
|
#define MB (1024*KB)
|
2008-07-24 11:27:54 +07:00
|
|
|
#define GB (1024L*MB)
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Note: pte --> Linux PTE
|
|
|
|
* HPTE --> PowerPC Hashed Page Table Entry
|
|
|
|
*
|
|
|
|
* Execution context:
|
|
|
|
* htab_initialize is called with the MMU off (of course), but
|
|
|
|
* the kernel has been copied down to zero so it can directly
|
|
|
|
* reference global data. At this point it is very difficult
|
|
|
|
* to print debug info.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2005-11-10 09:37:51 +07:00
|
|
|
static unsigned long _SDR1;
|
|
|
|
struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
|
2014-08-20 05:00:02 +07:00
|
|
|
EXPORT_SYMBOL_GPL(mmu_psize_defs);
|
2005-11-10 09:37:51 +07:00
|
|
|
|
2016-09-02 14:20:43 +07:00
|
|
|
u8 hpte_page_sizes[1 << LP_BITS];
|
|
|
|
EXPORT_SYMBOL_GPL(hpte_page_sizes);
|
|
|
|
|
2007-06-13 11:52:56 +07:00
|
|
|
struct hash_pte *htab_address;
|
2006-02-21 13:22:55 +07:00
|
|
|
unsigned long htab_size_bytes;
|
2005-07-13 15:11:42 +07:00
|
|
|
unsigned long htab_hash_mask;
|
2009-10-30 12:47:19 +07:00
|
|
|
EXPORT_SYMBOL_GPL(htab_hash_mask);
|
2005-11-07 07:06:55 +07:00
|
|
|
int mmu_linear_psize = MMU_PAGE_4K;
|
2014-10-08 15:54:54 +07:00
|
|
|
EXPORT_SYMBOL_GPL(mmu_linear_psize);
|
2005-11-07 07:06:55 +07:00
|
|
|
int mmu_virtual_psize = MMU_PAGE_4K;
|
2006-06-15 07:45:18 +07:00
|
|
|
int mmu_vmalloc_psize = MMU_PAGE_4K;
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 12:41:48 +07:00
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
int mmu_vmemmap_psize = MMU_PAGE_4K;
|
|
|
|
#endif
|
2006-06-15 07:45:18 +07:00
|
|
|
int mmu_io_psize = MMU_PAGE_4K;
|
2007-10-11 17:37:10 +07:00
|
|
|
int mmu_kernel_ssize = MMU_SEGSIZE_256M;
|
2014-10-08 15:54:54 +07:00
|
|
|
EXPORT_SYMBOL_GPL(mmu_kernel_ssize);
|
2007-10-11 17:37:10 +07:00
|
|
|
int mmu_highuser_ssize = MMU_SEGSIZE_256M;
|
2007-12-06 13:24:48 +07:00
|
|
|
u16 mmu_slb_size = 64;
|
2009-10-30 12:47:19 +07:00
|
|
|
EXPORT_SYMBOL_GPL(mmu_slb_size);
|
2006-06-15 07:45:18 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
|
|
|
int mmu_ci_restrictions;
|
|
|
|
#endif
|
2007-04-12 12:30:23 +07:00
|
|
|
#ifdef CONFIG_DEBUG_PAGEALLOC
|
|
|
|
static u8 *linear_map_hash_slots;
|
|
|
|
static unsigned long linear_map_hash_count;
|
2007-04-18 08:50:09 +07:00
|
|
|
static DEFINE_SPINLOCK(linear_map_hash_lock);
|
2007-04-12 12:30:23 +07:00
|
|
|
#endif /* CONFIG_DEBUG_PAGEALLOC */
|
2016-07-05 12:03:58 +07:00
|
|
|
struct mmu_hash_ops mmu_hash_ops;
|
|
|
|
EXPORT_SYMBOL(mmu_hash_ops);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* There are definitions of page sizes arrays to be used when none
|
|
|
|
* is provided by the firmware.
|
|
|
|
*/
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Pre-POWER4 CPUs (4k pages only)
|
|
|
|
*/
|
2008-05-08 11:27:07 +07:00
|
|
|
static struct mmu_psize_def mmu_psize_defaults_old[] = {
|
2005-11-07 07:06:55 +07:00
|
|
|
[MMU_PAGE_4K] = {
|
|
|
|
.shift = 12,
|
|
|
|
.sllp = 0,
|
2013-04-28 16:37:35 +07:00
|
|
|
.penc = {[MMU_PAGE_4K] = 0, [1 ... MMU_PAGE_COUNT - 1] = -1},
|
2005-11-07 07:06:55 +07:00
|
|
|
.avpnm = 0,
|
|
|
|
.tlbiel = 0,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
/* POWER4, GPUL, POWER5
|
|
|
|
*
|
|
|
|
* Support for 16Mb large pages
|
|
|
|
*/
|
2008-05-08 11:27:07 +07:00
|
|
|
static struct mmu_psize_def mmu_psize_defaults_gp[] = {
|
2005-11-07 07:06:55 +07:00
|
|
|
[MMU_PAGE_4K] = {
|
|
|
|
.shift = 12,
|
|
|
|
.sllp = 0,
|
2013-04-28 16:37:35 +07:00
|
|
|
.penc = {[MMU_PAGE_4K] = 0, [1 ... MMU_PAGE_COUNT - 1] = -1},
|
2005-11-07 07:06:55 +07:00
|
|
|
.avpnm = 0,
|
|
|
|
.tlbiel = 1,
|
|
|
|
},
|
|
|
|
[MMU_PAGE_16M] = {
|
|
|
|
.shift = 24,
|
|
|
|
.sllp = SLB_VSID_L,
|
2013-04-28 16:37:35 +07:00
|
|
|
.penc = {[0 ... MMU_PAGE_16M - 1] = -1, [MMU_PAGE_16M] = 0,
|
|
|
|
[MMU_PAGE_16M + 1 ... MMU_PAGE_COUNT - 1] = -1 },
|
2005-11-07 07:06:55 +07:00
|
|
|
.avpnm = 0x1UL,
|
|
|
|
.tlbiel = 0,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-05-31 13:26:30 +07:00
|
|
|
/*
|
|
|
|
* 'R' and 'C' update notes:
|
|
|
|
* - Under pHyp or KVM, the updatepp path will not set C, thus it *will*
|
|
|
|
* create writeable HPTEs without C set, because the hcall H_PROTECT
|
|
|
|
* that we use in that case will not update C
|
|
|
|
* - The above is however not a problem, because we also don't do that
|
|
|
|
* fancy "no flush" variant of eviction and we use H_REMOVE which will
|
|
|
|
* do the right thing and thus we don't have the race I described earlier
|
|
|
|
*
|
|
|
|
* - Under bare metal, we do have the race, so we need R and C set
|
|
|
|
* - We make sure R is always set and never lost
|
|
|
|
* - C is _PAGE_DIRTY, and *should* always be set for a writeable mapping
|
|
|
|
*/
|
2015-12-01 10:36:50 +07:00
|
|
|
unsigned long htab_convert_pte_flags(unsigned long pteflags)
|
2008-08-05 13:19:56 +07:00
|
|
|
{
|
2015-12-01 10:36:50 +07:00
|
|
|
unsigned long rflags = 0;
|
2008-08-05 13:19:56 +07:00
|
|
|
|
|
|
|
/* _PAGE_EXEC -> NOEXEC */
|
|
|
|
if ((pteflags & _PAGE_EXEC) == 0)
|
|
|
|
rflags |= HPTE_R_N;
|
2015-12-01 10:36:50 +07:00
|
|
|
/*
|
2016-04-29 20:25:36 +07:00
|
|
|
* PPP bits:
|
2016-02-22 09:41:12 +07:00
|
|
|
* Linux uses slb key 0 for kernel and 1 for user.
|
2016-04-29 20:25:36 +07:00
|
|
|
* kernel RW areas are mapped with PPP=0b000
|
|
|
|
* User area is mapped with PPP=0b010 for read/write
|
|
|
|
* or PPP=0b011 for read-only (including writeable but clean pages).
|
2008-08-05 13:19:56 +07:00
|
|
|
*/
|
2016-04-29 20:25:36 +07:00
|
|
|
if (pteflags & _PAGE_PRIVILEGED) {
|
|
|
|
/*
|
|
|
|
* Kernel read only mapped with ppp bits 0b110
|
|
|
|
*/
|
2016-11-24 16:39:54 +07:00
|
|
|
if (!(pteflags & _PAGE_WRITE)) {
|
|
|
|
if (mmu_has_feature(MMU_FTR_KERNEL_RO))
|
|
|
|
rflags |= (HPTE_R_PP0 | 0x2);
|
|
|
|
else
|
|
|
|
rflags |= 0x3;
|
|
|
|
}
|
2016-04-29 20:25:36 +07:00
|
|
|
} else {
|
2016-04-29 20:25:30 +07:00
|
|
|
if (pteflags & _PAGE_RWX)
|
|
|
|
rflags |= 0x2;
|
|
|
|
if (!((pteflags & _PAGE_WRITE) && (pteflags & _PAGE_DIRTY)))
|
2015-12-01 10:36:50 +07:00
|
|
|
rflags |= 0x1;
|
|
|
|
}
|
2013-11-18 16:28:10 +07:00
|
|
|
/*
|
2016-05-31 13:26:30 +07:00
|
|
|
* We can't allow hardware to update hpte bits. Hence always
|
|
|
|
* set 'R' bit and set 'C' if it is a write fault
|
2013-11-18 16:28:10 +07:00
|
|
|
*/
|
2016-06-17 13:02:00 +07:00
|
|
|
rflags |= HPTE_R_R;
|
2016-05-31 13:26:30 +07:00
|
|
|
|
|
|
|
if (pteflags & _PAGE_DIRTY)
|
|
|
|
rflags |= HPTE_R_C;
|
2015-12-01 10:36:51 +07:00
|
|
|
/*
|
|
|
|
* Add in WIG bits
|
|
|
|
*/
|
2016-04-29 20:25:38 +07:00
|
|
|
|
|
|
|
if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_TOLERANT)
|
2015-12-01 10:36:51 +07:00
|
|
|
rflags |= HPTE_R_I;
|
2016-06-17 13:02:00 +07:00
|
|
|
else if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_NON_IDEMPOTENT)
|
2016-04-29 20:25:38 +07:00
|
|
|
rflags |= (HPTE_R_I | HPTE_R_G);
|
2016-06-17 13:02:00 +07:00
|
|
|
else if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_SAO)
|
|
|
|
rflags |= (HPTE_R_W | HPTE_R_I | HPTE_R_M);
|
|
|
|
else
|
|
|
|
/*
|
|
|
|
* Add memory coherence if cache inhibited is not set
|
|
|
|
*/
|
|
|
|
rflags |= HPTE_R_M;
|
2015-12-01 10:36:51 +07:00
|
|
|
|
2018-01-19 08:50:36 +07:00
|
|
|
rflags |= pte_to_hpte_pkey_bits(pteflags);
|
2015-12-01 10:36:51 +07:00
|
|
|
return rflags;
|
2008-08-05 13:19:56 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
|
|
|
|
int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
|
2008-08-05 13:19:56 +07:00
|
|
|
unsigned long pstart, unsigned long prot,
|
2007-10-11 17:37:10 +07:00
|
|
|
int psize, int ssize)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2005-11-07 07:06:55 +07:00
|
|
|
unsigned long vaddr, paddr;
|
|
|
|
unsigned int step, shift;
|
|
|
|
int ret = 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
shift = mmu_psize_defs[psize].shift;
|
|
|
|
step = 1 << shift;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-08-05 13:19:56 +07:00
|
|
|
prot = htab_convert_pte_flags(prot);
|
|
|
|
|
|
|
|
DBG("htab_bolt_mapping(%lx..%lx -> %lx (%lx,%d,%d)\n",
|
|
|
|
vstart, vend, pstart, prot, psize, ssize);
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
for (vaddr = vstart, paddr = pstart; vaddr < vend;
|
|
|
|
vaddr += step, paddr += step) {
|
2007-04-12 12:30:23 +07:00
|
|
|
unsigned long hash, hpteg;
|
2007-10-11 17:37:10 +07:00
|
|
|
unsigned long vsid = get_kernel_vsid(vaddr, ssize);
|
2012-09-10 09:52:50 +07:00
|
|
|
unsigned long vpn = hpt_vpn(vaddr, vsid, ssize);
|
2008-08-30 08:26:27 +07:00
|
|
|
unsigned long tprot = prot;
|
|
|
|
|
2013-03-13 10:34:54 +07:00
|
|
|
/*
|
|
|
|
* If we hit a bad address return error.
|
|
|
|
*/
|
|
|
|
if (!vsid)
|
|
|
|
return -1;
|
2008-08-30 08:26:27 +07:00
|
|
|
/* Make kernel text executable */
|
powerpc: Make the 64-bit kernel as a position-independent executable
This implements CONFIG_RELOCATABLE for 64-bit by making the kernel as
a position-independent executable (PIE) when it is set. This involves
processing the dynamic relocations in the image in the early stages of
booting, even if the kernel is being run at the address it is linked at,
since the linker does not necessarily fill in words in the image for
which there are dynamic relocations. (In fact the linker does fill in
such words for 64-bit executables, though not for 32-bit executables,
so in principle we could avoid calling relocate() entirely when we're
running a 64-bit kernel at the linked address.)
The dynamic relocations are processed by a new function relocate(addr),
where the addr parameter is the virtual address where the image will be
run. In fact we call it twice; once before calling prom_init, and again
when starting the main kernel. This means that reloc_offset() returns
0 in prom_init (since it has been relocated to the address it is running
at), which necessitated a few adjustments.
This also changes __va and __pa to use an equivalent definition that is
simpler. With the relocatable kernel, PAGE_OFFSET and MEMORY_START are
constants (for 64-bit) whereas PHYSICAL_START is a variable (and
KERNELBASE ideally should be too, but isn't yet).
With this, relocatable kernels still copy themselves down to physical
address 0 and run there.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-30 08:43:47 +07:00
|
|
|
if (overlaps_kernel_text(vaddr, vaddr + step))
|
2008-08-30 08:26:27 +07:00
|
|
|
tprot &= ~HPTE_R_N;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2014-04-29 17:17:26 +07:00
|
|
|
/* Make kvm guest trampolines executable */
|
|
|
|
if (overlaps_kvm_tmp(vaddr, vaddr + step))
|
|
|
|
tprot &= ~HPTE_R_N;
|
|
|
|
|
2014-01-31 02:01:04 +07:00
|
|
|
/*
|
|
|
|
* If relocatable, check if it overlaps interrupt vectors that
|
|
|
|
* are copied down to real 0. For relocatable kernel
|
|
|
|
* (e.g. kdump case) we copy interrupt vectors down to real
|
|
|
|
* address 0. Mark that region as executable. This is
|
|
|
|
* because on p8 system with relocation on exception feature
|
|
|
|
* enabled, exceptions are raised with MMU (IR=DR=1) ON. Hence
|
|
|
|
* in order to execute the interrupt handlers in virtual
|
|
|
|
* mode the vector region need to be marked as executable.
|
|
|
|
*/
|
|
|
|
if ((PHYSICAL_START > MEMORY_START) &&
|
|
|
|
overlaps_interrupt_vector_text(vaddr, vaddr + step))
|
|
|
|
tprot &= ~HPTE_R_N;
|
|
|
|
|
2012-09-10 09:52:50 +07:00
|
|
|
hash = hpt_hash(vpn, shift, ssize);
|
2005-04-17 05:20:36 +07:00
|
|
|
hpteg = ((hash & htab_hash_mask) * HPTES_PER_GROUP);
|
|
|
|
|
2016-07-05 12:03:58 +07:00
|
|
|
BUG_ON(!mmu_hash_ops.hpte_insert);
|
|
|
|
ret = mmu_hash_ops.hpte_insert(hpteg, vpn, paddr, tprot,
|
|
|
|
HPTE_V_BOLTED, psize, psize,
|
|
|
|
ssize);
|
2006-06-23 15:16:39 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
if (ret < 0)
|
|
|
|
break;
|
2016-03-18 04:17:59 +07:00
|
|
|
|
2007-04-12 12:30:23 +07:00
|
|
|
#ifdef CONFIG_DEBUG_PAGEALLOC
|
2016-03-18 04:17:59 +07:00
|
|
|
if (debug_pagealloc_enabled() &&
|
|
|
|
(paddr >> PAGE_SHIFT) < linear_map_hash_count)
|
2007-04-12 12:30:23 +07:00
|
|
|
linear_map_hash_slots[paddr >> PAGE_SHIFT] = ret | 0x80;
|
|
|
|
#endif /* CONFIG_DEBUG_PAGEALLOC */
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
|
|
|
return ret < 0 ? ret : 0;
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2014-06-11 15:23:37 +07:00
|
|
|
int htab_remove_mapping(unsigned long vstart, unsigned long vend,
|
2008-01-29 05:19:24 +07:00
|
|
|
int psize, int ssize)
|
|
|
|
{
|
|
|
|
unsigned long vaddr;
|
|
|
|
unsigned int step, shift;
|
2016-02-09 10:32:41 +07:00
|
|
|
int rc;
|
|
|
|
int ret = 0;
|
2008-01-29 05:19:24 +07:00
|
|
|
|
|
|
|
shift = mmu_psize_defs[psize].shift;
|
|
|
|
step = 1 << shift;
|
|
|
|
|
2016-07-05 12:03:58 +07:00
|
|
|
if (!mmu_hash_ops.hpte_removebolted)
|
2016-02-09 10:32:40 +07:00
|
|
|
return -ENODEV;
|
2008-01-29 05:19:24 +07:00
|
|
|
|
2016-02-09 10:32:41 +07:00
|
|
|
for (vaddr = vstart; vaddr < vend; vaddr += step) {
|
2016-07-05 12:03:58 +07:00
|
|
|
rc = mmu_hash_ops.hpte_removebolted(vaddr, psize, ssize);
|
2016-02-09 10:32:41 +07:00
|
|
|
if (rc == -ENOENT) {
|
|
|
|
ret = -ENOENT;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (rc < 0)
|
|
|
|
return rc;
|
|
|
|
}
|
2008-03-28 07:37:21 +07:00
|
|
|
|
2016-02-09 10:32:41 +07:00
|
|
|
return ret;
|
2008-01-29 05:19:24 +07:00
|
|
|
}
|
|
|
|
|
2016-07-05 08:43:21 +07:00
|
|
|
static bool disable_1tb_segments = false;
|
|
|
|
|
|
|
|
static int __init parse_disable_1tb_segments(char *p)
|
|
|
|
{
|
|
|
|
disable_1tb_segments = true;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("disable_1tb_segments", parse_disable_1tb_segments);
|
|
|
|
|
2007-10-11 17:37:10 +07:00
|
|
|
static int __init htab_dt_scan_seg_sizes(unsigned long node,
|
|
|
|
const char *uname, int depth,
|
|
|
|
void *data)
|
|
|
|
{
|
2014-04-02 11:49:03 +07:00
|
|
|
const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
|
|
|
|
const __be32 *prop;
|
|
|
|
int size = 0;
|
2007-10-11 17:37:10 +07:00
|
|
|
|
|
|
|
/* We are scanning "cpu" nodes only */
|
|
|
|
if (type == NULL || strcmp(type, "cpu") != 0)
|
|
|
|
return 0;
|
|
|
|
|
2013-09-23 09:04:36 +07:00
|
|
|
prop = of_get_flat_dt_prop(node, "ibm,processor-segment-sizes", &size);
|
2007-10-11 17:37:10 +07:00
|
|
|
if (prop == NULL)
|
|
|
|
return 0;
|
|
|
|
for (; size >= 4; size -= 4, ++prop) {
|
2013-09-23 09:04:36 +07:00
|
|
|
if (be32_to_cpu(prop[0]) == 40) {
|
2007-10-11 17:37:10 +07:00
|
|
|
DBG("1T segment support detected\n");
|
2016-07-05 08:43:21 +07:00
|
|
|
|
|
|
|
if (disable_1tb_segments) {
|
|
|
|
DBG("1T segments disabled by command line\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-04-07 02:48:50 +07:00
|
|
|
cur_cpu_spec->mmu_features |= MMU_FTR_1T_SEGMENT;
|
2007-10-12 13:44:55 +07:00
|
|
|
return 1;
|
2007-10-11 17:37:10 +07:00
|
|
|
}
|
|
|
|
}
|
2011-04-07 02:48:50 +07:00
|
|
|
cur_cpu_spec->mmu_features &= ~MMU_FTR_NO_SLBIE_B;
|
2007-10-11 17:37:10 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-04-28 16:37:35 +07:00
|
|
|
static int __init get_idx_from_shift(unsigned int shift)
|
|
|
|
{
|
|
|
|
int idx = -1;
|
|
|
|
|
|
|
|
switch (shift) {
|
|
|
|
case 0xc:
|
|
|
|
idx = MMU_PAGE_4K;
|
|
|
|
break;
|
|
|
|
case 0x10:
|
|
|
|
idx = MMU_PAGE_64K;
|
|
|
|
break;
|
|
|
|
case 0x14:
|
|
|
|
idx = MMU_PAGE_1M;
|
|
|
|
break;
|
|
|
|
case 0x18:
|
|
|
|
idx = MMU_PAGE_16M;
|
|
|
|
break;
|
|
|
|
case 0x22:
|
|
|
|
idx = MMU_PAGE_16G;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return idx;
|
|
|
|
}
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
static int __init htab_dt_scan_page_sizes(unsigned long node,
|
|
|
|
const char *uname, int depth,
|
|
|
|
void *data)
|
|
|
|
{
|
2014-04-02 11:49:03 +07:00
|
|
|
const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
|
|
|
|
const __be32 *prop;
|
|
|
|
int size = 0;
|
2005-11-07 07:06:55 +07:00
|
|
|
|
|
|
|
/* We are scanning "cpu" nodes only */
|
|
|
|
if (type == NULL || strcmp(type, "cpu") != 0)
|
|
|
|
return 0;
|
|
|
|
|
2013-09-23 09:04:36 +07:00
|
|
|
prop = of_get_flat_dt_prop(node, "ibm,segment-page-sizes", &size);
|
2014-08-07 14:26:33 +07:00
|
|
|
if (!prop)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pr_info("Page sizes from device-tree:\n");
|
|
|
|
size /= 4;
|
|
|
|
cur_cpu_spec->mmu_features &= ~(MMU_FTR_16M_PAGE);
|
|
|
|
while(size > 0) {
|
|
|
|
unsigned int base_shift = be32_to_cpu(prop[0]);
|
|
|
|
unsigned int slbenc = be32_to_cpu(prop[1]);
|
|
|
|
unsigned int lpnum = be32_to_cpu(prop[2]);
|
|
|
|
struct mmu_psize_def *def;
|
|
|
|
int idx, base_idx;
|
|
|
|
|
|
|
|
size -= 3; prop += 3;
|
|
|
|
base_idx = get_idx_from_shift(base_shift);
|
|
|
|
if (base_idx < 0) {
|
|
|
|
/* skip the pte encoding also */
|
|
|
|
prop += lpnum * 2; size -= lpnum * 2;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
def = &mmu_psize_defs[base_idx];
|
|
|
|
if (base_idx == MMU_PAGE_16M)
|
|
|
|
cur_cpu_spec->mmu_features |= MMU_FTR_16M_PAGE;
|
|
|
|
|
|
|
|
def->shift = base_shift;
|
|
|
|
if (base_shift <= 23)
|
|
|
|
def->avpnm = 0;
|
|
|
|
else
|
|
|
|
def->avpnm = (1 << (base_shift - 23)) - 1;
|
|
|
|
def->sllp = slbenc;
|
|
|
|
/*
|
|
|
|
* We don't know for sure what's up with tlbiel, so
|
|
|
|
* for now we only set it for 4K and 64K pages
|
|
|
|
*/
|
|
|
|
if (base_idx == MMU_PAGE_4K || base_idx == MMU_PAGE_64K)
|
|
|
|
def->tlbiel = 1;
|
|
|
|
else
|
|
|
|
def->tlbiel = 0;
|
|
|
|
|
|
|
|
while (size > 0 && lpnum) {
|
|
|
|
unsigned int shift = be32_to_cpu(prop[0]);
|
|
|
|
int penc = be32_to_cpu(prop[1]);
|
|
|
|
|
|
|
|
prop += 2; size -= 2;
|
|
|
|
lpnum--;
|
|
|
|
|
|
|
|
idx = get_idx_from_shift(shift);
|
|
|
|
if (idx < 0)
|
2013-04-28 16:37:35 +07:00
|
|
|
continue;
|
2014-08-07 14:26:33 +07:00
|
|
|
|
|
|
|
if (penc == -1)
|
|
|
|
pr_err("Invalid penc for base_shift=%d "
|
|
|
|
"shift=%d\n", base_shift, shift);
|
|
|
|
|
|
|
|
def->penc[idx] = penc;
|
|
|
|
pr_info("base_shift=%d: shift=%d, sllp=0x%04lx,"
|
|
|
|
" avpnm=0x%08lx, tlbiel=%d, penc=%d\n",
|
|
|
|
base_shift, shift, def->sllp,
|
|
|
|
def->avpnm, def->tlbiel, def->penc[idx]);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
2014-08-07 14:26:33 +07:00
|
|
|
|
|
|
|
return 1;
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
|
|
|
|
2008-07-31 10:51:42 +07:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
2008-07-24 11:27:54 +07:00
|
|
|
/* Scan for 16G memory blocks that have been set aside for huge pages
|
|
|
|
* and reserve those blocks for 16G huge pages.
|
|
|
|
*/
|
|
|
|
static int __init htab_dt_scan_hugepage_blocks(unsigned long node,
|
|
|
|
const char *uname, int depth,
|
|
|
|
void *data) {
|
2014-04-02 11:49:03 +07:00
|
|
|
const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
|
|
|
|
const __be64 *addr_prop;
|
|
|
|
const __be32 *page_count_prop;
|
2008-07-24 11:27:54 +07:00
|
|
|
unsigned int expected_pages;
|
|
|
|
long unsigned int phys_addr;
|
|
|
|
long unsigned int block_size;
|
|
|
|
|
|
|
|
/* We are scanning "memory" nodes only */
|
|
|
|
if (type == NULL || strcmp(type, "memory") != 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* This property is the log base 2 of the number of virtual pages that
|
|
|
|
* will represent this memory block. */
|
|
|
|
page_count_prop = of_get_flat_dt_prop(node, "ibm,expected#pages", NULL);
|
|
|
|
if (page_count_prop == NULL)
|
|
|
|
return 0;
|
2013-09-23 09:04:36 +07:00
|
|
|
expected_pages = (1 << be32_to_cpu(page_count_prop[0]));
|
2008-07-24 11:27:54 +07:00
|
|
|
addr_prop = of_get_flat_dt_prop(node, "reg", NULL);
|
|
|
|
if (addr_prop == NULL)
|
|
|
|
return 0;
|
2013-09-23 09:04:36 +07:00
|
|
|
phys_addr = be64_to_cpu(addr_prop[0]);
|
|
|
|
block_size = be64_to_cpu(addr_prop[1]);
|
2008-07-24 11:27:54 +07:00
|
|
|
if (block_size != (16 * GB))
|
|
|
|
return 0;
|
|
|
|
printk(KERN_INFO "Huge page(16GB) memory: "
|
|
|
|
"addr = 0x%lX size = 0x%lX pages = %d\n",
|
|
|
|
phys_addr, block_size, expected_pages);
|
2017-01-12 16:09:06 +07:00
|
|
|
if (phys_addr + block_size * expected_pages <= memblock_end_of_DRAM()) {
|
2010-07-12 11:36:09 +07:00
|
|
|
memblock_reserve(phys_addr, block_size * expected_pages);
|
2017-07-28 12:01:26 +07:00
|
|
|
pseries_add_gpage(phys_addr, block_size, expected_pages);
|
2008-10-21 22:27:36 +07:00
|
|
|
}
|
2008-07-24 11:27:54 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2008-07-31 10:51:42 +07:00
|
|
|
#endif /* CONFIG_HUGETLB_PAGE */
|
2008-07-24 11:27:54 +07:00
|
|
|
|
2013-04-28 16:37:35 +07:00
|
|
|
static void mmu_psize_set_default_penc(void)
|
|
|
|
{
|
|
|
|
int bpsize, apsize;
|
|
|
|
for (bpsize = 0; bpsize < MMU_PAGE_COUNT; bpsize++)
|
|
|
|
for (apsize = 0; apsize < MMU_PAGE_COUNT; apsize++)
|
|
|
|
mmu_psize_defs[bpsize].penc[apsize] = -1;
|
|
|
|
}
|
|
|
|
|
2014-04-01 20:46:05 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
|
|
|
|
|
|
|
static bool might_have_hea(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The HEA ethernet adapter requires awareness of the
|
|
|
|
* GX bus. Without that awareness we can easily assume
|
|
|
|
* we will never see an HEA ethernet device.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_IBMEBUS
|
2016-07-05 12:03:56 +07:00
|
|
|
return !cpu_has_feature(CPU_FTR_ARCH_207S) &&
|
2016-10-11 17:15:04 +07:00
|
|
|
firmware_has_feature(FW_FEATURE_SPLPAR);
|
2014-04-01 20:46:05 +07:00
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* #ifdef CONFIG_PPC_64K_PAGES */
|
|
|
|
|
2016-07-26 18:31:59 +07:00
|
|
|
static void __init htab_scan_page_sizes(void)
|
2005-11-07 07:06:55 +07:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2013-04-28 16:37:35 +07:00
|
|
|
/* se the invalid penc to -1 */
|
|
|
|
mmu_psize_set_default_penc();
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Default to 4K pages only */
|
|
|
|
memcpy(mmu_psize_defs, mmu_psize_defaults_old,
|
|
|
|
sizeof(mmu_psize_defaults_old));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to find the available page sizes in the device-tree
|
|
|
|
*/
|
|
|
|
rc = of_scan_flat_dt(htab_dt_scan_page_sizes, NULL);
|
2016-07-23 16:12:35 +07:00
|
|
|
if (rc == 0 && early_mmu_has_feature(MMU_FTR_16M_PAGE)) {
|
2016-07-26 18:31:59 +07:00
|
|
|
/*
|
|
|
|
* Nothing in the device-tree, but the CPU supports 16M pages,
|
|
|
|
* so let's fallback on a known size list for 16M capable CPUs.
|
|
|
|
*/
|
2005-11-07 07:06:55 +07:00
|
|
|
memcpy(mmu_psize_defs, mmu_psize_defaults_gp,
|
|
|
|
sizeof(mmu_psize_defaults_gp));
|
2016-07-26 18:31:59 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
/* Reserve 16G huge page memory sections for huge pages */
|
|
|
|
of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
|
|
|
|
#endif /* CONFIG_HUGETLB_PAGE */
|
|
|
|
}
|
|
|
|
|
2016-09-02 14:20:43 +07:00
|
|
|
/*
|
|
|
|
* Fill in the hpte_page_sizes[] array.
|
|
|
|
* We go through the mmu_psize_defs[] array looking for all the
|
|
|
|
* supported base/actual page size combinations. Each combination
|
|
|
|
* has a unique pagesize encoding (penc) value in the low bits of
|
|
|
|
* the LP field of the HPTE. For actual page sizes less than 1MB,
|
|
|
|
* some of the upper LP bits are used for RPN bits, meaning that
|
|
|
|
* we need to fill in several entries in hpte_page_sizes[].
|
|
|
|
*
|
|
|
|
* In diagrammatic form, with r = RPN bits and z = page size bits:
|
|
|
|
* PTE LP actual page size
|
|
|
|
* rrrr rrrz >=8KB
|
|
|
|
* rrrr rrzz >=16KB
|
|
|
|
* rrrr rzzz >=32KB
|
|
|
|
* rrrr zzzz >=64KB
|
|
|
|
* ...
|
|
|
|
*
|
|
|
|
* The zzzz bits are implementation-specific but are chosen so that
|
|
|
|
* no encoding for a larger page size uses the same value in its
|
|
|
|
* low-order N bits as the encoding for the 2^(12+N) byte page size
|
|
|
|
* (if it exists).
|
|
|
|
*/
|
|
|
|
static void init_hpte_page_sizes(void)
|
|
|
|
{
|
|
|
|
long int ap, bp;
|
|
|
|
long int shift, penc;
|
|
|
|
|
|
|
|
for (bp = 0; bp < MMU_PAGE_COUNT; ++bp) {
|
|
|
|
if (!mmu_psize_defs[bp].shift)
|
|
|
|
continue; /* not a supported page size */
|
|
|
|
for (ap = bp; ap < MMU_PAGE_COUNT; ++ap) {
|
|
|
|
penc = mmu_psize_defs[bp].penc[ap];
|
2017-11-28 15:34:40 +07:00
|
|
|
if (penc == -1 || !mmu_psize_defs[ap].shift)
|
2016-09-02 14:20:43 +07:00
|
|
|
continue;
|
|
|
|
shift = mmu_psize_defs[ap].shift - LP_SHIFT;
|
|
|
|
if (shift <= 0)
|
|
|
|
continue; /* should never happen */
|
|
|
|
/*
|
|
|
|
* For page sizes less than 1MB, this loop
|
|
|
|
* replicates the entry for all possible values
|
|
|
|
* of the rrrr bits.
|
|
|
|
*/
|
|
|
|
while (penc < (1 << LP_BITS)) {
|
|
|
|
hpte_page_sizes[penc] = (ap << 4) | bp;
|
|
|
|
penc += 1 << shift;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-26 18:31:59 +07:00
|
|
|
static void __init htab_init_page_sizes(void)
|
|
|
|
{
|
2016-09-02 14:20:43 +07:00
|
|
|
init_hpte_page_sizes();
|
|
|
|
|
2016-03-18 04:17:59 +07:00
|
|
|
if (!debug_pagealloc_enabled()) {
|
|
|
|
/*
|
|
|
|
* Pick a size for the linear mapping. Currently, we only
|
|
|
|
* support 16M, 1M and 4K which is the default
|
|
|
|
*/
|
|
|
|
if (mmu_psize_defs[MMU_PAGE_16M].shift)
|
|
|
|
mmu_linear_psize = MMU_PAGE_16M;
|
|
|
|
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
|
|
|
|
mmu_linear_psize = MMU_PAGE_1M;
|
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2006-06-15 07:45:18 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
2005-11-07 07:06:55 +07:00
|
|
|
/*
|
|
|
|
* Pick a size for the ordinary pages. Default is 4K, we support
|
2006-06-15 07:45:18 +07:00
|
|
|
* 64K for user mappings and vmalloc if supported by the processor.
|
|
|
|
* We only use 64k for ioremap if the processor
|
|
|
|
* (and firmware) support cache-inhibited large pages.
|
|
|
|
* If not, we use 4k and set mmu_ci_restrictions so that
|
|
|
|
* hash_page knows to switch processes that use cache-inhibited
|
|
|
|
* mappings to 4k pages.
|
2005-11-07 07:06:55 +07:00
|
|
|
*/
|
2006-06-15 07:45:18 +07:00
|
|
|
if (mmu_psize_defs[MMU_PAGE_64K].shift) {
|
2005-11-07 07:06:55 +07:00
|
|
|
mmu_virtual_psize = MMU_PAGE_64K;
|
2006-06-15 07:45:18 +07:00
|
|
|
mmu_vmalloc_psize = MMU_PAGE_64K;
|
2007-04-12 12:30:23 +07:00
|
|
|
if (mmu_linear_psize == MMU_PAGE_4K)
|
|
|
|
mmu_linear_psize = MMU_PAGE_64K;
|
2011-04-07 02:48:50 +07:00
|
|
|
if (mmu_has_feature(MMU_FTR_CI_LARGE_PAGE)) {
|
2008-03-24 13:41:22 +07:00
|
|
|
/*
|
2014-04-01 20:46:05 +07:00
|
|
|
* When running on pSeries using 64k pages for ioremap
|
|
|
|
* would stop us accessing the HEA ethernet. So if we
|
|
|
|
* have the chance of ever seeing one, stay at 4k.
|
2008-03-24 13:41:22 +07:00
|
|
|
*/
|
2016-07-05 12:03:56 +07:00
|
|
|
if (!might_have_hea())
|
2008-03-24 13:41:22 +07:00
|
|
|
mmu_io_psize = MMU_PAGE_64K;
|
|
|
|
} else
|
2006-06-15 07:45:18 +07:00
|
|
|
mmu_ci_restrictions = 1;
|
|
|
|
}
|
2007-04-12 12:30:23 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
2005-11-07 07:06:55 +07:00
|
|
|
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 12:41:48 +07:00
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
/* We try to use 16M pages for vmemmap if that is supported
|
|
|
|
* and we have at least 1G of RAM at boot
|
|
|
|
*/
|
|
|
|
if (mmu_psize_defs[MMU_PAGE_16M].shift &&
|
2010-07-12 11:36:09 +07:00
|
|
|
memblock_phys_mem_size() >= 0x40000000)
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 12:41:48 +07:00
|
|
|
mmu_vmemmap_psize = MMU_PAGE_16M;
|
|
|
|
else if (mmu_psize_defs[MMU_PAGE_64K].shift)
|
|
|
|
mmu_vmemmap_psize = MMU_PAGE_64K;
|
|
|
|
else
|
|
|
|
mmu_vmemmap_psize = MMU_PAGE_4K;
|
|
|
|
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
|
|
|
|
|
2006-06-15 07:45:18 +07:00
|
|
|
printk(KERN_DEBUG "Page orders: linear mapping = %d, "
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 12:41:48 +07:00
|
|
|
"virtual = %d, io = %d"
|
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
", vmemmap = %d"
|
|
|
|
#endif
|
|
|
|
"\n",
|
2005-11-07 07:06:55 +07:00
|
|
|
mmu_psize_defs[mmu_linear_psize].shift,
|
2006-06-15 07:45:18 +07:00
|
|
|
mmu_psize_defs[mmu_virtual_psize].shift,
|
[POWERPC] vmemmap fixes to use smaller pages
This changes vmemmap to use a different region (region 0xf) of the
address space, and to configure the page size of that region
dynamically at boot.
The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.
In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's "additional" memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.
The logic used by my match to choose the vmemmap page size is:
- If 16M pages are available and there's 1G or more RAM at boot,
use that size.
- Else if 64K pages are available, use that
- Else use 4K pages
I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.
Note that I intend to change the way we organize the kernel regions &
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-30 12:41:48 +07:00
|
|
|
mmu_psize_defs[mmu_io_psize].shift
|
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
,mmu_psize_defs[mmu_vmemmap_psize].shift
|
|
|
|
#endif
|
|
|
|
);
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init htab_dt_scan_pftsize(unsigned long node,
|
|
|
|
const char *uname, int depth,
|
|
|
|
void *data)
|
|
|
|
{
|
2014-04-02 11:49:03 +07:00
|
|
|
const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
|
|
|
|
const __be32 *prop;
|
2005-11-07 07:06:55 +07:00
|
|
|
|
|
|
|
/* We are scanning "cpu" nodes only */
|
|
|
|
if (type == NULL || strcmp(type, "cpu") != 0)
|
|
|
|
return 0;
|
|
|
|
|
2013-09-23 09:04:36 +07:00
|
|
|
prop = of_get_flat_dt_prop(node, "ibm,pft-size", NULL);
|
2005-11-07 07:06:55 +07:00
|
|
|
if (prop != NULL) {
|
|
|
|
/* pft_size[0] is the NUMA CEC cookie */
|
2013-09-23 09:04:36 +07:00
|
|
|
ppc64_pft_size = be32_to_cpu(prop[1]);
|
2005-11-07 07:06:55 +07:00
|
|
|
return 1;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
return 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2016-02-09 10:32:43 +07:00
|
|
|
unsigned htab_shift_for_mem_size(unsigned long mem_size)
|
2005-10-12 13:58:53 +07:00
|
|
|
{
|
2016-02-09 10:32:43 +07:00
|
|
|
unsigned memshift = __ilog2(mem_size);
|
|
|
|
unsigned pshift = mmu_psize_defs[mmu_virtual_psize].shift;
|
|
|
|
unsigned pteg_shift;
|
|
|
|
|
|
|
|
/* round mem_size up to next power of 2 */
|
|
|
|
if ((1UL << memshift) < mem_size)
|
|
|
|
memshift += 1;
|
2005-10-12 13:58:53 +07:00
|
|
|
|
2016-02-09 10:32:43 +07:00
|
|
|
/* aim for 2 pages / pteg */
|
|
|
|
pteg_shift = memshift - (pshift + 1);
|
2005-10-12 13:58:53 +07:00
|
|
|
|
2016-02-09 10:32:43 +07:00
|
|
|
/*
|
|
|
|
* 2^11 PTEGS of 128 bytes each, ie. 2^18 bytes is the minimum htab
|
|
|
|
* size permitted by the architecture.
|
|
|
|
*/
|
|
|
|
return max(pteg_shift + 7, 18U);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long __init htab_get_table_size(void)
|
|
|
|
{
|
2005-11-07 07:06:55 +07:00
|
|
|
/* If hash size isn't already provided by the platform, we try to
|
2006-01-10 06:10:13 +07:00
|
|
|
* retrieve it from the device-tree. If it's not there neither, we
|
2005-11-07 07:06:55 +07:00
|
|
|
* calculate it now based on the total RAM size
|
2005-10-12 13:58:53 +07:00
|
|
|
*/
|
2005-11-07 07:06:55 +07:00
|
|
|
if (ppc64_pft_size == 0)
|
|
|
|
of_scan_flat_dt(htab_dt_scan_pftsize, NULL);
|
2005-10-12 13:58:53 +07:00
|
|
|
if (ppc64_pft_size)
|
|
|
|
return 1UL << ppc64_pft_size;
|
|
|
|
|
2016-02-09 10:32:43 +07:00
|
|
|
return 1UL << htab_shift_for_mem_size(memblock_phys_mem_size());
|
2005-10-12 13:58:53 +07:00
|
|
|
}
|
|
|
|
|
2005-11-08 07:25:48 +07:00
|
|
|
#ifdef CONFIG_MEMORY_HOTPLUG
|
2016-12-09 07:07:38 +07:00
|
|
|
void resize_hpt_for_hotplug(unsigned long new_mem_size)
|
|
|
|
{
|
|
|
|
unsigned target_hpt_shift;
|
|
|
|
|
|
|
|
if (!mmu_hash_ops.resize_hpt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
target_hpt_shift = htab_shift_for_mem_size(new_mem_size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To avoid lots of HPT resizes if memory size is fluctuating
|
|
|
|
* across a boundary, we deliberately have some hysterisis
|
|
|
|
* here: we immediately increase the HPT size if the target
|
|
|
|
* shift exceeds the current shift, but we won't attempt to
|
|
|
|
* reduce unless the target shift is at least 2 below the
|
|
|
|
* current shift
|
|
|
|
*/
|
|
|
|
if ((target_hpt_shift > ppc64_pft_size)
|
|
|
|
|| (target_hpt_shift < (ppc64_pft_size - 1))) {
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = mmu_hash_ops.resize_hpt(target_hpt_shift);
|
2017-03-17 08:11:19 +07:00
|
|
|
if (rc && (rc != -ENODEV))
|
2016-12-09 07:07:38 +07:00
|
|
|
printk(KERN_WARNING
|
|
|
|
"Unable to resize hash page table to target order %d: %d\n",
|
|
|
|
target_hpt_shift, rc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-04 03:39:51 +07:00
|
|
|
int hash__create_section_mapping(unsigned long start, unsigned long end)
|
2005-11-08 07:25:48 +07:00
|
|
|
{
|
2016-02-09 10:32:42 +07:00
|
|
|
int rc = htab_bolt_mapping(start, end, __pa(start),
|
|
|
|
pgprot_val(PAGE_KERNEL), mmu_linear_psize,
|
|
|
|
mmu_kernel_ssize);
|
|
|
|
|
|
|
|
if (rc < 0) {
|
|
|
|
int rc2 = htab_remove_mapping(start, end, mmu_linear_psize,
|
|
|
|
mmu_kernel_ssize);
|
|
|
|
BUG_ON(rc2 && (rc2 != -ENOENT));
|
|
|
|
}
|
|
|
|
return rc;
|
2005-11-08 07:25:48 +07:00
|
|
|
}
|
2008-01-29 05:19:24 +07:00
|
|
|
|
2017-01-04 03:39:51 +07:00
|
|
|
int hash__remove_section_mapping(unsigned long start, unsigned long end)
|
2008-01-29 05:19:24 +07:00
|
|
|
{
|
2016-02-09 10:32:40 +07:00
|
|
|
int rc = htab_remove_mapping(start, end, mmu_linear_psize,
|
|
|
|
mmu_kernel_ssize);
|
|
|
|
WARN_ON(rc < 0);
|
|
|
|
return rc;
|
2008-01-29 05:19:24 +07:00
|
|
|
}
|
2005-11-08 07:25:48 +07:00
|
|
|
#endif /* CONFIG_MEMORY_HOTPLUG */
|
|
|
|
|
2016-08-24 16:33:39 +07:00
|
|
|
static void update_hid_for_hash(void)
|
|
|
|
{
|
|
|
|
unsigned long hid0;
|
|
|
|
unsigned long rb = 3UL << PPC_BITLSHIFT(53); /* IS = 3 */
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
/* prs = 0, ric = 2, rs = 0, r = 1 is = 3 */
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
: : "r"(rb), "i"(0), "i"(0), "i"(2), "r"(0) : "memory");
|
|
|
|
asm volatile("eieio; tlbsync; ptesync; isync; slbia": : :"memory");
|
2017-04-11 12:23:25 +07:00
|
|
|
trace_tlbie(0, 0, rb, 0, 2, 0, 0);
|
|
|
|
|
2016-08-24 16:33:39 +07:00
|
|
|
/*
|
|
|
|
* now switch the HID
|
|
|
|
*/
|
|
|
|
hid0 = mfspr(SPRN_HID0);
|
|
|
|
hid0 &= ~HID0_POWER9_RADIX;
|
|
|
|
mtspr(SPRN_HID0, hid0);
|
|
|
|
asm volatile("isync": : :"memory");
|
|
|
|
|
|
|
|
/* Wait for it to happen */
|
|
|
|
while ((mfspr(SPRN_HID0) & HID0_POWER9_RADIX))
|
|
|
|
cpu_relax();
|
|
|
|
}
|
|
|
|
|
2016-04-29 20:25:43 +07:00
|
|
|
static void __init hash_init_partition_table(phys_addr_t hash_table,
|
2016-07-13 16:35:26 +07:00
|
|
|
unsigned long htab_size)
|
2016-04-29 20:25:43 +07:00
|
|
|
{
|
2016-11-21 12:00:58 +07:00
|
|
|
mmu_partition_table_init();
|
2016-04-29 20:25:43 +07:00
|
|
|
|
|
|
|
/*
|
2016-11-21 12:00:58 +07:00
|
|
|
* PS field (VRMA page size) is not used for LPID 0, hence set to 0.
|
|
|
|
* For now, UPRT is 0 and we have no segment table.
|
2016-04-29 20:25:43 +07:00
|
|
|
*/
|
2016-07-13 16:35:26 +07:00
|
|
|
htab_size = __ilog2(htab_size) - 18;
|
2016-11-21 12:00:58 +07:00
|
|
|
mmu_partition_table_set_entry(0, hash_table | htab_size, 0);
|
2016-07-13 16:35:25 +07:00
|
|
|
pr_info("Partition table %p\n", partition_tb);
|
2016-08-24 16:33:39 +07:00
|
|
|
if (cpu_has_feature(CPU_FTR_POWER9_DD1))
|
|
|
|
update_hid_for_hash();
|
2016-04-29 20:25:43 +07:00
|
|
|
}
|
|
|
|
|
2009-03-20 02:34:16 +07:00
|
|
|
static void __init htab_initialize(void)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2006-02-21 13:22:55 +07:00
|
|
|
unsigned long table;
|
2005-04-17 05:20:36 +07:00
|
|
|
unsigned long pteg_count;
|
2008-08-30 08:26:27 +07:00
|
|
|
unsigned long prot;
|
2016-07-05 12:03:53 +07:00
|
|
|
unsigned long base = 0, size = 0;
|
2010-08-04 10:43:53 +07:00
|
|
|
struct memblock_region *reg;
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
DBG(" -> htab_initialize()\n");
|
|
|
|
|
2011-04-07 02:48:50 +07:00
|
|
|
if (mmu_has_feature(MMU_FTR_1T_SEGMENT)) {
|
2007-10-11 17:37:10 +07:00
|
|
|
mmu_kernel_ssize = MMU_SEGSIZE_1T;
|
|
|
|
mmu_highuser_ssize = MMU_SEGSIZE_1T;
|
|
|
|
printk(KERN_INFO "Using 1TB segments\n");
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Calculate the required size of the htab. We want the number of
|
|
|
|
* PTEGs to equal one half the number of real pages.
|
|
|
|
*/
|
2005-11-07 07:06:55 +07:00
|
|
|
htab_size_bytes = htab_get_table_size();
|
2005-04-17 05:20:36 +07:00
|
|
|
pteg_count = htab_size_bytes >> 7;
|
|
|
|
|
|
|
|
htab_hash_mask = pteg_count - 1;
|
|
|
|
|
2016-07-05 12:03:53 +07:00
|
|
|
if (firmware_has_feature(FW_FEATURE_LPAR) ||
|
|
|
|
firmware_has_feature(FW_FEATURE_PS3_LV1)) {
|
2005-04-17 05:20:36 +07:00
|
|
|
/* Using a hypervisor which owns the htab */
|
|
|
|
htab_address = NULL;
|
|
|
|
_SDR1 = 0;
|
2012-02-20 09:15:03 +07:00
|
|
|
#ifdef CONFIG_FA_DUMP
|
|
|
|
/*
|
|
|
|
* If firmware assisted dump is active firmware preserves
|
|
|
|
* the contents of htab along with entire partition memory.
|
|
|
|
* Clear the htab if firmware assisted dump is active so
|
|
|
|
* that we dont end up using old mappings.
|
|
|
|
*/
|
2016-07-05 12:03:58 +07:00
|
|
|
if (is_fadump_active() && mmu_hash_ops.hpte_clear_all)
|
|
|
|
mmu_hash_ops.hpte_clear_all();
|
2012-02-20 09:15:03 +07:00
|
|
|
#endif
|
2005-04-17 05:20:36 +07:00
|
|
|
} else {
|
2016-07-05 12:03:53 +07:00
|
|
|
unsigned long limit = MEMBLOCK_ALLOC_ANYWHERE;
|
|
|
|
|
|
|
|
#ifdef CONFIG_PPC_CELL
|
|
|
|
/*
|
|
|
|
* Cell may require the hash table down low when using the
|
|
|
|
* Axon IOMMU in order to fit the dynamic region over it, see
|
|
|
|
* comments in cell/iommu.c
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2016-07-05 12:03:53 +07:00
|
|
|
if (fdt_subnode_offset(initial_boot_params, 0, "axon") > 0) {
|
2008-03-12 14:03:24 +07:00
|
|
|
limit = 0x80000000;
|
2016-07-05 12:03:53 +07:00
|
|
|
pr_info("Hash table forced below 2G for Axon IOMMU\n");
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PPC_CELL */
|
2008-01-29 21:13:59 +07:00
|
|
|
|
2016-07-05 12:03:53 +07:00
|
|
|
table = memblock_alloc_base(htab_size_bytes, htab_size_bytes,
|
|
|
|
limit);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
DBG("Hash table allocated at %lx, size: %lx\n", table,
|
|
|
|
htab_size_bytes);
|
|
|
|
|
2012-07-26 04:19:50 +07:00
|
|
|
htab_address = __va(table);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/* htab absolute addr + encoded htabsize */
|
2016-07-13 16:35:26 +07:00
|
|
|
_SDR1 = table + __ilog2(htab_size_bytes) - 18;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/* Initialize the HPT with no entries */
|
|
|
|
memset((void *)table, 0, htab_size_bytes);
|
2005-11-10 09:37:51 +07:00
|
|
|
|
2016-04-29 20:25:43 +07:00
|
|
|
if (!cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
/* Set SDR1 */
|
|
|
|
mtspr(SPRN_SDR1, _SDR1);
|
|
|
|
else
|
2016-07-13 16:35:26 +07:00
|
|
|
hash_init_partition_table(table, htab_size_bytes);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2008-10-13 00:54:24 +07:00
|
|
|
prot = pgprot_val(PAGE_KERNEL);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2007-04-12 12:30:23 +07:00
|
|
|
#ifdef CONFIG_DEBUG_PAGEALLOC
|
2016-03-18 04:17:59 +07:00
|
|
|
if (debug_pagealloc_enabled()) {
|
|
|
|
linear_map_hash_count = memblock_end_of_DRAM() >> PAGE_SHIFT;
|
|
|
|
linear_map_hash_slots = __va(memblock_alloc_base(
|
|
|
|
linear_map_hash_count, 1, ppc64_rma_size));
|
|
|
|
memset(linear_map_hash_slots, 0, linear_map_hash_count);
|
|
|
|
}
|
2007-04-12 12:30:23 +07:00
|
|
|
#endif /* CONFIG_DEBUG_PAGEALLOC */
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* create bolted the linear mapping in the hash table */
|
2010-08-04 10:43:53 +07:00
|
|
|
for_each_memblock(memory, reg) {
|
|
|
|
base = (unsigned long)__va(reg->base);
|
|
|
|
size = reg->size;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-12-14 04:15:12 +07:00
|
|
|
DBG("creating mapping for region: %lx..%lx (prot: %lx)\n",
|
2008-08-30 08:26:27 +07:00
|
|
|
base, size, prot);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2006-03-21 16:45:51 +07:00
|
|
|
BUG_ON(htab_bolt_mapping(base, base + size, __pa(base),
|
2008-08-30 08:26:27 +07:00
|
|
|
prot, mmu_linear_psize, mmu_kernel_ssize));
|
2010-07-07 05:39:01 +07:00
|
|
|
}
|
|
|
|
memblock_set_current_limit(MEMBLOCK_ALLOC_ANYWHERE);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have a memory_limit and we've allocated TCEs then we need to
|
|
|
|
* explicitly map the TCE area at the top of RAM. We also cope with the
|
|
|
|
* case that the TCEs start below memory_limit.
|
|
|
|
* tce_alloc_start/end are 16MB aligned so the mapping should work
|
|
|
|
* for either 4K or 16MB pages.
|
|
|
|
*/
|
|
|
|
if (tce_alloc_start) {
|
2005-12-05 23:24:33 +07:00
|
|
|
tce_alloc_start = (unsigned long)__va(tce_alloc_start);
|
|
|
|
tce_alloc_end = (unsigned long)__va(tce_alloc_end);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
if (base + size >= tce_alloc_start)
|
|
|
|
tce_alloc_start = base + size + 1;
|
|
|
|
|
2006-03-21 16:45:51 +07:00
|
|
|
BUG_ON(htab_bolt_mapping(tce_alloc_start, tce_alloc_end,
|
2008-08-05 13:19:56 +07:00
|
|
|
__pa(tce_alloc_start), prot,
|
2007-10-11 17:37:10 +07:00
|
|
|
mmu_linear_psize, mmu_kernel_ssize));
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2006-06-23 15:16:38 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
DBG(" <- htab_initialize()\n");
|
|
|
|
}
|
|
|
|
#undef KB
|
|
|
|
#undef MB
|
|
|
|
|
2016-07-26 18:31:59 +07:00
|
|
|
void __init hash__early_init_devtree(void)
|
|
|
|
{
|
|
|
|
/* Initialize segment sizes */
|
|
|
|
of_scan_flat_dt(htab_dt_scan_seg_sizes, NULL);
|
|
|
|
|
|
|
|
/* Initialize page sizes */
|
|
|
|
htab_scan_page_sizes();
|
|
|
|
}
|
|
|
|
|
2016-04-29 20:25:57 +07:00
|
|
|
void __init hash__early_init_mmu(void)
|
2005-11-10 09:37:51 +07:00
|
|
|
{
|
powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6,
in the 4K backed HPTE pages.These bits continue to be used
for 64K backed HPTE pages in this patch, but will be freed
up in the next patch. The bit numbers are big-endian as
defined in the ISA3.0
The patch does the following change to the 4k HTPE backed
64K PTE's format.
H_PAGE_BUSY moves from bit 3 to bit 9 (B bit in the figure
below)
V0 which occupied bit 4 is not used anymore.
V1 which occupied bit 5 is not used anymore.
V2 which occupied bit 6 is not used anymore.
V3 which occupied bit 7 is not used anymore.
Before the patch, the 4k backed 64k PTE format was as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x|B|V0|V1|V2|V3|x| | |x|x|................|x|x|x|x| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
After the patch, the 4k backed 64k PTE format is as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x| | | | | |x|B| |x|x|................|.|.|.|.| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
the four bits S,G,I,X (one quadruplet per 4k HPTE) that
cache the hash-bucket slot value, is initialized to
1,1,1,1 indicating -- an invalid slot. If a HPTE gets
cached in a 1111 slot(i.e 7th slot of secondary hash
bucket), it is released immediately. In other words,
even though 1111 is a valid slot value in the hash
bucket, we consider it invalid and release the slot and
the HPTE. This gives us the opportunity to determine
the validity of S,G,I,X bits based on its contents and
not on any of the bits V0,V1,V2 or V3 in the primary PTE
When we release a HPTE cached in the 1111 slot
we also release a legitimate slot in the primary
hash bucket and unmap its corresponding HPTE. This
is to ensure that we do get a HPTE cached in a slot
of the primary hash bucket, the next time we retry.
Though treating 1111 slot as invalid, reduces the
number of available slots in the hash bucket and may
have an effect on the performance, the probabilty of
hitting a 1111 slot is extermely low.
Compared to the current scheme, the above scheme
reduces the number of false hash table updates
significantly and has the added advantage of releasing
four valuable PTE bits for other purpose.
NOTE:even though bits 3, 4, 5, 6, 7 are not used when
the 64K PTE is backed by 4k HPTE, they continue to be
used if the PTE gets backed by 64k HPTE. The next
patch will decouple that aswell, and truely release the
bits.
This idea was jointly developed by Paul Mackerras,
Aneesh, Michael Ellermen and myself.
4K PTE format remains unchanged currently.
The patch does the following code changes
a) PTE flags are split between 64k and 4k header files.
b) __hash_page_4K() is reimplemented to reflect the
above logic.
Acked-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-06 15:50:47 +07:00
|
|
|
#ifndef CONFIG_PPC_64K_PAGES
|
2017-03-28 11:21:12 +07:00
|
|
|
/*
|
powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6,
in the 4K backed HPTE pages.These bits continue to be used
for 64K backed HPTE pages in this patch, but will be freed
up in the next patch. The bit numbers are big-endian as
defined in the ISA3.0
The patch does the following change to the 4k HTPE backed
64K PTE's format.
H_PAGE_BUSY moves from bit 3 to bit 9 (B bit in the figure
below)
V0 which occupied bit 4 is not used anymore.
V1 which occupied bit 5 is not used anymore.
V2 which occupied bit 6 is not used anymore.
V3 which occupied bit 7 is not used anymore.
Before the patch, the 4k backed 64k PTE format was as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x|B|V0|V1|V2|V3|x| | |x|x|................|x|x|x|x| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
After the patch, the 4k backed 64k PTE format is as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x| | | | | |x|B| |x|x|................|.|.|.|.| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
the four bits S,G,I,X (one quadruplet per 4k HPTE) that
cache the hash-bucket slot value, is initialized to
1,1,1,1 indicating -- an invalid slot. If a HPTE gets
cached in a 1111 slot(i.e 7th slot of secondary hash
bucket), it is released immediately. In other words,
even though 1111 is a valid slot value in the hash
bucket, we consider it invalid and release the slot and
the HPTE. This gives us the opportunity to determine
the validity of S,G,I,X bits based on its contents and
not on any of the bits V0,V1,V2 or V3 in the primary PTE
When we release a HPTE cached in the 1111 slot
we also release a legitimate slot in the primary
hash bucket and unmap its corresponding HPTE. This
is to ensure that we do get a HPTE cached in a slot
of the primary hash bucket, the next time we retry.
Though treating 1111 slot as invalid, reduces the
number of available slots in the hash bucket and may
have an effect on the performance, the probabilty of
hitting a 1111 slot is extermely low.
Compared to the current scheme, the above scheme
reduces the number of false hash table updates
significantly and has the added advantage of releasing
four valuable PTE bits for other purpose.
NOTE:even though bits 3, 4, 5, 6, 7 are not used when
the 64K PTE is backed by 4k HPTE, they continue to be
used if the PTE gets backed by 64k HPTE. The next
patch will decouple that aswell, and truely release the
bits.
This idea was jointly developed by Paul Mackerras,
Aneesh, Michael Ellermen and myself.
4K PTE format remains unchanged currently.
The patch does the following code changes
a) PTE flags are split between 64k and 4k header files.
b) __hash_page_4K() is reimplemented to reflect the
above logic.
Acked-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-06 15:50:47 +07:00
|
|
|
* We have code in __hash_page_4K() and elsewhere, which assumes it can
|
2017-03-28 11:21:12 +07:00
|
|
|
* do the following:
|
|
|
|
* new_pte |= (slot << H_PAGE_F_GIX_SHIFT) & (H_PAGE_F_SECOND | H_PAGE_F_GIX);
|
|
|
|
*
|
|
|
|
* Where the slot number is between 0-15, and values of 8-15 indicate
|
|
|
|
* the secondary bucket. For that code to work H_PAGE_F_SECOND and
|
|
|
|
* H_PAGE_F_GIX must occupy four contiguous bits in the PTE, and
|
|
|
|
* H_PAGE_F_SECOND must be placed above H_PAGE_F_GIX. Assert that here
|
|
|
|
* with a BUILD_BUG_ON().
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(H_PAGE_F_SECOND != (1ul << (H_PAGE_F_GIX_SHIFT + 3)));
|
powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6,
in the 4K backed HPTE pages.These bits continue to be used
for 64K backed HPTE pages in this patch, but will be freed
up in the next patch. The bit numbers are big-endian as
defined in the ISA3.0
The patch does the following change to the 4k HTPE backed
64K PTE's format.
H_PAGE_BUSY moves from bit 3 to bit 9 (B bit in the figure
below)
V0 which occupied bit 4 is not used anymore.
V1 which occupied bit 5 is not used anymore.
V2 which occupied bit 6 is not used anymore.
V3 which occupied bit 7 is not used anymore.
Before the patch, the 4k backed 64k PTE format was as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x|B|V0|V1|V2|V3|x| | |x|x|................|x|x|x|x| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
After the patch, the 4k backed 64k PTE format is as follows
0 1 2 3 4 5 6 7 8 9 10...........................63
: : : : : : : : : : : :
v v v v v v v v v v v v
,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-,
|x|x|x| | | | | |x|B| |x|x|................|.|.|.|.| <- primary pte
'_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_'
|S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte
'_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_'
the four bits S,G,I,X (one quadruplet per 4k HPTE) that
cache the hash-bucket slot value, is initialized to
1,1,1,1 indicating -- an invalid slot. If a HPTE gets
cached in a 1111 slot(i.e 7th slot of secondary hash
bucket), it is released immediately. In other words,
even though 1111 is a valid slot value in the hash
bucket, we consider it invalid and release the slot and
the HPTE. This gives us the opportunity to determine
the validity of S,G,I,X bits based on its contents and
not on any of the bits V0,V1,V2 or V3 in the primary PTE
When we release a HPTE cached in the 1111 slot
we also release a legitimate slot in the primary
hash bucket and unmap its corresponding HPTE. This
is to ensure that we do get a HPTE cached in a slot
of the primary hash bucket, the next time we retry.
Though treating 1111 slot as invalid, reduces the
number of available slots in the hash bucket and may
have an effect on the performance, the probabilty of
hitting a 1111 slot is extermely low.
Compared to the current scheme, the above scheme
reduces the number of false hash table updates
significantly and has the added advantage of releasing
four valuable PTE bits for other purpose.
NOTE:even though bits 3, 4, 5, 6, 7 are not used when
the 64K PTE is backed by 4k HPTE, they continue to be
used if the PTE gets backed by 64k HPTE. The next
patch will decouple that aswell, and truely release the
bits.
This idea was jointly developed by Paul Mackerras,
Aneesh, Michael Ellermen and myself.
4K PTE format remains unchanged currently.
The patch does the following code changes
a) PTE flags are split between 64k and 4k header files.
b) __hash_page_4K() is reimplemented to reflect the
above logic.
Acked-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-06 15:50:47 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
2017-03-28 11:21:12 +07:00
|
|
|
|
2016-07-26 18:31:59 +07:00
|
|
|
htab_init_page_sizes();
|
|
|
|
|
2016-04-29 20:25:49 +07:00
|
|
|
/*
|
|
|
|
* initialize page table size
|
|
|
|
*/
|
2016-04-29 20:26:23 +07:00
|
|
|
__pte_frag_nr = H_PTE_FRAG_NR;
|
|
|
|
__pte_frag_size_shift = H_PTE_FRAG_SIZE_SHIFT;
|
|
|
|
|
2016-04-29 20:25:49 +07:00
|
|
|
__pte_index_size = H_PTE_INDEX_SIZE;
|
|
|
|
__pmd_index_size = H_PMD_INDEX_SIZE;
|
|
|
|
__pud_index_size = H_PUD_INDEX_SIZE;
|
|
|
|
__pgd_index_size = H_PGD_INDEX_SIZE;
|
2018-02-11 22:00:06 +07:00
|
|
|
__pud_cache_index = H_PUD_CACHE_INDEX;
|
2016-04-29 20:25:49 +07:00
|
|
|
__pmd_cache_index = H_PMD_CACHE_INDEX;
|
|
|
|
__pte_table_size = H_PTE_TABLE_SIZE;
|
|
|
|
__pmd_table_size = H_PMD_TABLE_SIZE;
|
|
|
|
__pud_table_size = H_PUD_TABLE_SIZE;
|
|
|
|
__pgd_table_size = H_PGD_TABLE_SIZE;
|
2016-04-29 20:26:19 +07:00
|
|
|
/*
|
|
|
|
* 4k use hugepd format, so for hash set then to
|
|
|
|
* zero
|
|
|
|
*/
|
|
|
|
__pmd_val_bits = 0;
|
|
|
|
__pud_val_bits = 0;
|
|
|
|
__pgd_val_bits = 0;
|
2016-04-29 20:26:21 +07:00
|
|
|
|
|
|
|
__kernel_virt_start = H_KERN_VIRT_START;
|
|
|
|
__kernel_virt_size = H_KERN_VIRT_SIZE;
|
|
|
|
__vmalloc_start = H_VMALLOC_START;
|
|
|
|
__vmalloc_end = H_VMALLOC_END;
|
2017-08-01 17:29:22 +07:00
|
|
|
__kernel_io_start = H_KERN_IO_START;
|
2016-04-29 20:26:21 +07:00
|
|
|
vmemmap = (struct page *)H_VMEMMAP_BASE;
|
|
|
|
ioremap_bot = IOREMAP_BASE;
|
|
|
|
|
2016-06-30 03:06:28 +07:00
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
pci_io_base = ISA_IO_BASE;
|
|
|
|
#endif
|
|
|
|
|
2016-07-05 12:03:51 +07:00
|
|
|
/* Select appropriate backend */
|
|
|
|
if (firmware_has_feature(FW_FEATURE_PS3_LV1))
|
|
|
|
ps3_early_mm_init();
|
|
|
|
else if (firmware_has_feature(FW_FEATURE_LPAR))
|
2016-07-26 07:33:03 +07:00
|
|
|
hpte_init_pseries();
|
2016-07-28 09:35:02 +07:00
|
|
|
else if (IS_ENABLED(CONFIG_PPC_NATIVE))
|
2016-07-05 12:03:51 +07:00
|
|
|
hpte_init_native();
|
|
|
|
|
2016-07-25 08:54:41 +07:00
|
|
|
if (!mmu_hash_ops.hpte_insert)
|
|
|
|
panic("hash__early_init_mmu: No MMU hash ops defined!\n");
|
|
|
|
|
2009-03-20 02:34:16 +07:00
|
|
|
/* Initialize the MMU Hash table and create the linear mapping
|
2014-07-10 09:29:19 +07:00
|
|
|
* of memory. Has to be done before SLB initialization as this is
|
|
|
|
* currently where the page size encoding is obtained.
|
2009-03-20 02:34:16 +07:00
|
|
|
*/
|
|
|
|
htab_initialize();
|
|
|
|
|
2016-07-13 16:35:25 +07:00
|
|
|
pr_info("Initializing hash mmu with SLB\n");
|
2014-07-10 09:29:19 +07:00
|
|
|
/* Initialize SLB management */
|
2014-07-10 09:29:20 +07:00
|
|
|
slb_initialize();
|
powerpc/64s: Improve local TLB flush for boot and MCE on POWER9
There are several cases outside the normal address space management
where a CPU's entire local TLB is to be flushed:
1. Booting the kernel, in case something has left stale entries in
the TLB (e.g., kexec).
2. Machine check, to clean corrupted TLB entries.
One other place where the TLB is flushed, is waking from deep idle
states. The flush is a side-effect of calling ->cpu_restore with the
intention of re-setting various SPRs. The flush itself is unnecessary
because in the first case, the TLB should not acquire new corrupted
TLB entries as part of sleep/wake (though they may be lost).
This type of TLB flush is coded inflexibly, several times for each CPU
type, and they have a number of problems with ISA v3.0B:
- The current radix mode of the MMU is not taken into account, it is
always done as a hash flushn For IS=2 (LPID-matching flush from host)
and IS=3 with HV=0 (guest kernel flush), tlbie(l) is undefined if
the R field does not match the current radix mode.
- ISA v3.0B hash must flush the partition and process table caches as
well.
- ISA v3.0B radix must flush partition and process scoped translations,
partition and process table caches, and also the page walk cache.
So consolidate the flushing code and implement it in C and inline asm
under the mm/ directory with the rest of the flush code. Add ISA v3.0B
cases for radix and hash, and use the radix flush in radix environment.
Provide a way for IS=2 (LPID flush) to specify the radix mode of the
partition. Have KVM pass in the radix mode of the guest.
Take out the flushes from early cputable/dt_cpu_ftrs detection hooks,
and move it later in the boot process after, the MMU registers are set
up and before relocation is first turned on.
The TLB flush is no longer called when restoring from deep idle states.
This was not be done as a separate step because booting secondaries
uses the same cpu_restore as idle restore, which needs the TLB flush.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-23 22:15:50 +07:00
|
|
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_206)
|
|
|
|
&& cpu_has_feature(CPU_FTR_HVMODE))
|
|
|
|
tlbiel_all();
|
2009-03-20 02:34:16 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
2016-04-29 20:25:57 +07:00
|
|
|
void hash__early_init_mmu_secondary(void)
|
2009-03-20 02:34:16 +07:00
|
|
|
{
|
|
|
|
/* Initialize hash table for that CPU */
|
2016-04-29 20:26:12 +07:00
|
|
|
if (!firmware_has_feature(FW_FEATURE_LPAR)) {
|
2016-11-17 17:16:23 +07:00
|
|
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_POWER9_DD1))
|
|
|
|
update_hid_for_hash();
|
|
|
|
|
2016-04-29 20:26:12 +07:00
|
|
|
if (!cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
mtspr(SPRN_SDR1, _SDR1);
|
|
|
|
else
|
|
|
|
mtspr(SPRN_PTCR,
|
|
|
|
__pa(partition_tb) | (PATB_SIZE_SHIFT - 12));
|
|
|
|
}
|
2014-07-10 09:29:19 +07:00
|
|
|
/* Initialize SLB */
|
2014-07-10 09:29:20 +07:00
|
|
|
slb_initialize();
|
powerpc/64s: Improve local TLB flush for boot and MCE on POWER9
There are several cases outside the normal address space management
where a CPU's entire local TLB is to be flushed:
1. Booting the kernel, in case something has left stale entries in
the TLB (e.g., kexec).
2. Machine check, to clean corrupted TLB entries.
One other place where the TLB is flushed, is waking from deep idle
states. The flush is a side-effect of calling ->cpu_restore with the
intention of re-setting various SPRs. The flush itself is unnecessary
because in the first case, the TLB should not acquire new corrupted
TLB entries as part of sleep/wake (though they may be lost).
This type of TLB flush is coded inflexibly, several times for each CPU
type, and they have a number of problems with ISA v3.0B:
- The current radix mode of the MMU is not taken into account, it is
always done as a hash flushn For IS=2 (LPID-matching flush from host)
and IS=3 with HV=0 (guest kernel flush), tlbie(l) is undefined if
the R field does not match the current radix mode.
- ISA v3.0B hash must flush the partition and process table caches as
well.
- ISA v3.0B radix must flush partition and process scoped translations,
partition and process table caches, and also the page walk cache.
So consolidate the flushing code and implement it in C and inline asm
under the mm/ directory with the rest of the flush code. Add ISA v3.0B
cases for radix and hash, and use the radix flush in radix environment.
Provide a way for IS=2 (LPID flush) to specify the radix mode of the
partition. Have KVM pass in the radix mode of the guest.
Take out the flushes from early cputable/dt_cpu_ftrs detection hooks,
and move it later in the boot process after, the MMU registers are set
up and before relocation is first turned on.
The TLB flush is no longer called when restoring from deep idle states.
This was not be done as a separate step because booting secondaries
uses the same cpu_restore as idle restore, which needs the TLB flush.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-23 22:15:50 +07:00
|
|
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_206)
|
|
|
|
&& cpu_has_feature(CPU_FTR_HVMODE))
|
|
|
|
tlbiel_all();
|
2005-11-10 09:37:51 +07:00
|
|
|
}
|
2009-03-20 02:34:16 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
2005-11-10 09:37:51 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Called by asm hashtable.S for doing lazy icache flush
|
|
|
|
*/
|
|
|
|
unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap)
|
|
|
|
{
|
|
|
|
struct page *page;
|
|
|
|
|
2005-11-08 07:21:05 +07:00
|
|
|
if (!pfn_valid(pte_pfn(pte)))
|
|
|
|
return pp;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
page = pte_page(pte);
|
|
|
|
|
|
|
|
/* page is dirty */
|
|
|
|
if (!test_bit(PG_arch_1, &page->flags) && !PageReserved(page)) {
|
|
|
|
if (trap == 0x400) {
|
2009-10-27 02:24:31 +07:00
|
|
|
flush_dcache_icache_page(page);
|
2005-04-17 05:20:36 +07:00
|
|
|
set_bit(PG_arch_1, &page->flags);
|
|
|
|
} else
|
2005-11-07 07:06:55 +07:00
|
|
|
pp |= HPTE_R_N;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
return pp;
|
|
|
|
}
|
|
|
|
|
2008-06-18 12:29:12 +07:00
|
|
|
#ifdef CONFIG_PPC_MM_SLICES
|
2014-08-20 05:55:18 +07:00
|
|
|
static unsigned int get_paca_psize(unsigned long addr)
|
2008-06-18 12:29:12 +07:00
|
|
|
{
|
2018-02-22 21:27:28 +07:00
|
|
|
unsigned char *psizes;
|
2012-09-10 09:52:52 +07:00
|
|
|
unsigned long index, mask_index;
|
2008-06-18 12:29:12 +07:00
|
|
|
|
|
|
|
if (addr < SLICE_LOW_TOP) {
|
2018-02-22 21:27:28 +07:00
|
|
|
psizes = get_paca()->mm_ctx_low_slices_psize;
|
2008-06-18 12:29:12 +07:00
|
|
|
index = GET_LOW_SLICE_INDEX(addr);
|
2018-02-22 21:27:28 +07:00
|
|
|
} else {
|
|
|
|
psizes = get_paca()->mm_ctx_high_slices_psize;
|
|
|
|
index = GET_HIGH_SLICE_INDEX(addr);
|
2008-06-18 12:29:12 +07:00
|
|
|
}
|
2012-09-10 09:52:52 +07:00
|
|
|
mask_index = index & 0x1;
|
2018-02-22 21:27:28 +07:00
|
|
|
return (psizes[index >> 1] >> (mask_index * 4)) & 0xF;
|
2008-06-18 12:29:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
unsigned int get_paca_psize(unsigned long addr)
|
|
|
|
{
|
2016-01-09 04:25:01 +07:00
|
|
|
return get_paca()->mm_ctx_user_psize;
|
2008-06-18 12:29:12 +07:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 18:24:02 +07:00
|
|
|
/*
|
|
|
|
* Demote a segment to using 4k pages.
|
|
|
|
* For now this makes the whole process use 4k pages.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
|
2007-05-08 13:27:27 +07:00
|
|
|
{
|
2008-06-18 12:29:12 +07:00
|
|
|
if (get_slice_psize(mm, addr) == MMU_PAGE_4K)
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 18:24:02 +07:00
|
|
|
return;
|
2008-06-18 12:29:12 +07:00
|
|
|
slice_set_range_psize(mm, addr, 1, MMU_PAGE_4K);
|
2014-10-08 15:54:52 +07:00
|
|
|
copro_flush_all_slbs(mm);
|
2014-10-08 15:54:58 +07:00
|
|
|
if ((get_paca_psize(addr) != MMU_PAGE_4K) && (current->mm == mm)) {
|
2015-10-28 11:54:06 +07:00
|
|
|
|
2017-03-22 10:36:49 +07:00
|
|
|
copy_mm_to_paca(mm);
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
slb_flush_and_rebolt();
|
|
|
|
}
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 18:24:02 +07:00
|
|
|
}
|
2007-05-08 13:27:27 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 18:24:02 +07:00
|
|
|
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
#ifdef CONFIG_PPC_SUBPAGE_PROT
|
|
|
|
/*
|
|
|
|
* This looks up a 2-bit protection code for a 4k subpage of a 64k page.
|
|
|
|
* Userspace sets the subpage permissions using the subpage_prot system call.
|
|
|
|
*
|
|
|
|
* Result is 0: full permissions, _PAGE_RW: read-only,
|
2016-04-29 20:25:31 +07:00
|
|
|
* _PAGE_RWX: no access.
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
*/
|
2009-11-27 01:56:04 +07:00
|
|
|
static int subpage_protection(struct mm_struct *mm, unsigned long ea)
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
{
|
2009-11-27 01:56:04 +07:00
|
|
|
struct subpage_prot_table *spt = &mm->context.spt;
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
u32 spp = 0;
|
|
|
|
u32 **sbpm, *sbpp;
|
|
|
|
|
|
|
|
if (ea >= spt->maxaddr)
|
|
|
|
return 0;
|
2013-08-06 23:01:24 +07:00
|
|
|
if (ea < 0x100000000UL) {
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
/* addresses below 4GB use spt->low_prot */
|
|
|
|
sbpm = spt->low_prot;
|
|
|
|
} else {
|
|
|
|
sbpm = spt->protptrs[ea >> SBP_L3_SHIFT];
|
|
|
|
if (!sbpm)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
sbpp = sbpm[(ea >> SBP_L2_SHIFT) & (SBP_L2_COUNT - 1)];
|
|
|
|
if (!sbpp)
|
|
|
|
return 0;
|
|
|
|
spp = sbpp[(ea >> PAGE_SHIFT) & (SBP_L1_COUNT - 1)];
|
|
|
|
|
|
|
|
/* extract 2-bit bitfield for this 4k subpage */
|
|
|
|
spp >>= 30 - 2 * ((ea >> 12) & 0xf);
|
|
|
|
|
2016-04-29 20:25:31 +07:00
|
|
|
/*
|
|
|
|
* 0 -> full premission
|
|
|
|
* 1 -> Read only
|
|
|
|
* 2 -> no access.
|
|
|
|
* We return the flag that need to be cleared.
|
|
|
|
*/
|
|
|
|
spp = ((spp & 2) ? _PAGE_RWX : 0) | ((spp & 1) ? _PAGE_WRITE : 0);
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
return spp;
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_PPC_SUBPAGE_PROT */
|
2009-11-27 01:56:04 +07:00
|
|
|
static inline int subpage_protection(struct mm_struct *mm, unsigned long ea)
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-07-23 07:31:13 +07:00
|
|
|
void hash_failure_debug(unsigned long ea, unsigned long access,
|
|
|
|
unsigned long vsid, unsigned long trap,
|
2013-04-28 16:37:37 +07:00
|
|
|
int ssize, int psize, int lpsize, unsigned long pte)
|
2010-07-23 07:31:13 +07:00
|
|
|
{
|
|
|
|
if (!printk_ratelimit())
|
|
|
|
return;
|
|
|
|
pr_info("mm: Hashing failure ! EA=0x%lx access=0x%lx current=%s\n",
|
|
|
|
ea, access, current->comm);
|
2013-04-28 16:37:37 +07:00
|
|
|
pr_info(" trap=0x%lx vsid=0x%lx ssize=%d base psize=%d psize %d pte=0x%lx\n",
|
|
|
|
trap, vsid, ssize, psize, lpsize, pte);
|
2010-07-23 07:31:13 +07:00
|
|
|
}
|
|
|
|
|
powerpc/mm: Check paca psize is up to date for huge mappings
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.
The bug is as follows:
1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa0000000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.
We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.
The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.
We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.
Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.
Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.11+]
2014-05-28 15:21:17 +07:00
|
|
|
static void check_paca_psize(unsigned long ea, struct mm_struct *mm,
|
|
|
|
int psize, bool user_region)
|
|
|
|
{
|
|
|
|
if (user_region) {
|
|
|
|
if (psize != get_paca_psize(ea)) {
|
2017-03-22 10:36:49 +07:00
|
|
|
copy_mm_to_paca(mm);
|
powerpc/mm: Check paca psize is up to date for huge mappings
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.
The bug is as follows:
1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa0000000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.
We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.
The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.
We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.
Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.
Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.11+]
2014-05-28 15:21:17 +07:00
|
|
|
slb_flush_and_rebolt();
|
|
|
|
}
|
|
|
|
} else if (get_paca()->vmalloc_sllp !=
|
|
|
|
mmu_psize_defs[mmu_vmalloc_psize].sllp) {
|
|
|
|
get_paca()->vmalloc_sllp =
|
|
|
|
mmu_psize_defs[mmu_vmalloc_psize].sllp;
|
|
|
|
slb_vmalloc_update();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* Result code is:
|
|
|
|
* 0 - handled
|
|
|
|
* 1 - normal page fault
|
|
|
|
* -1 - critical hash insertion error
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
* -2 - access not permitted by subpage protection mechanism
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2014-12-04 12:30:14 +07:00
|
|
|
int hash_page_mm(struct mm_struct *mm, unsigned long ea,
|
|
|
|
unsigned long access, unsigned long trap,
|
|
|
|
unsigned long flags)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2015-10-09 10:02:21 +07:00
|
|
|
bool is_thp;
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
enum ctx_state prev_state = exception_enter();
|
2009-12-16 21:29:56 +07:00
|
|
|
pgd_t *pgdir;
|
2005-04-17 05:20:36 +07:00
|
|
|
unsigned long vsid;
|
|
|
|
pte_t *ptep;
|
powerpc/mm: Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing "special" hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-10-27 02:24:31 +07:00
|
|
|
unsigned hugeshift;
|
2014-12-04 12:30:14 +07:00
|
|
|
int rc, user_region = 0;
|
2007-10-11 17:37:10 +07:00
|
|
|
int psize, ssize;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
|
|
|
|
ea, access, trap);
|
powerpc/mm: Add trace point for tracking hash pte fault
This enables us to understand how many hash fault we are taking
when running benchmarks.
For ex:
-bash-4.2# ./perf stat -e powerpc:hash_fault -e page-faults /tmp/ebizzy.ppc64 -S 30 -P -n 1000
...
Performance counter stats for '/tmp/ebizzy.ppc64 -S 30 -P -n 1000':
1,10,04,075 powerpc:hash_fault
1,10,03,429 page-faults
30.865978991 seconds time elapsed
NOTE:
The impact of the tracepoint was not noticeable when running test. It was
within the run-time variance of the test. For ex:
without-patch:
--------------
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.089 M/sec
7.236562 task-clock (msec) # 0.928 CPUs utilized
2,179,213 stalled-cycles-frontend # 0.00% frontend cycles idle
17,174,367 stalled-cycles-backend # 0.00% backend cycles idle
0 context-switches # 0.000 K/sec
0.007794658 seconds time elapsed
And with-patch:
---------------
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.089 M/sec
7.233746 task-clock (msec) # 0.921 CPUs utilized
0 context-switches # 0.000 K/sec
0.007854876 seconds time elapsed
Performance counter stats for './a.out 3000 300':
643 page-faults # 0.087 M/sec
649 powerpc:hash_fault # 0.087 M/sec
7.430376 task-clock (msec) # 0.938 CPUs utilized
2,347,174 stalled-cycles-frontend # 0.00% frontend cycles idle
17,524,282 stalled-cycles-backend # 0.00% backend cycles idle
0 context-switches # 0.000 K/sec
0.007920284 seconds time elapsed
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-04-14 14:35:57 +07:00
|
|
|
trace_hash_fault(ea, access, trap);
|
2005-05-06 06:15:13 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Get region & vsid */
|
2005-04-17 05:20:36 +07:00
|
|
|
switch (REGION_ID(ea)) {
|
|
|
|
case USER_REGION_ID:
|
|
|
|
user_region = 1;
|
2005-11-07 07:06:55 +07:00
|
|
|
if (! mm) {
|
|
|
|
DBG_LOW(" user region with no mm !\n");
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
2007-05-08 13:27:28 +07:00
|
|
|
psize = get_slice_psize(mm, ea);
|
2007-10-11 17:37:10 +07:00
|
|
|
ssize = user_segment_size(ea);
|
|
|
|
vsid = get_vsid(mm->context.id, ea, ssize);
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
|
|
|
case VMALLOC_REGION_ID:
|
2007-10-11 17:37:10 +07:00
|
|
|
vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
|
2006-06-15 07:45:18 +07:00
|
|
|
if (ea < VMALLOC_END)
|
|
|
|
psize = mmu_vmalloc_psize;
|
|
|
|
else
|
|
|
|
psize = mmu_io_psize;
|
2007-10-11 17:37:10 +07:00
|
|
|
ssize = mmu_kernel_ssize;
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* Not a valid range
|
|
|
|
* Send the problem up to do_page_fault
|
|
|
|
*/
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
DBG_LOW(" mm=%p, mm->pgdir=%p, vsid=%016lx\n", mm, mm->pgd, vsid);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-03-13 10:34:54 +07:00
|
|
|
/* Bad address. */
|
|
|
|
if (!vsid) {
|
|
|
|
DBG_LOW("Bad address!\n");
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
2013-03-13 10:34:54 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Get pgdir */
|
2005-04-17 05:20:36 +07:00
|
|
|
pgdir = mm->pgd;
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
if (pgdir == NULL) {
|
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Check CPU locality */
|
2017-07-24 11:28:01 +07:00
|
|
|
if (user_region && mm_is_thread_local(mm))
|
2014-12-04 12:30:14 +07:00
|
|
|
flags |= HPTE_LOCAL_UPDATE;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2007-05-08 13:27:28 +07:00
|
|
|
#ifndef CONFIG_PPC_64K_PAGES
|
powerpc/mm: Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing "special" hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-10-27 02:24:31 +07:00
|
|
|
/* If we use 4K pages and our psize is not 4K, then we might
|
|
|
|
* be hitting a special driver mapping, and need to align the
|
|
|
|
* address before we fetch the PTE.
|
|
|
|
*
|
|
|
|
* It could also be a hugepage mapping, in which case this is
|
|
|
|
* not necessary, but it's not harmful, either.
|
2007-05-08 13:27:28 +07:00
|
|
|
*/
|
|
|
|
if (psize != MMU_PAGE_4K)
|
|
|
|
ea &= ~((1ul << mmu_psize_defs[psize].shift) - 1);
|
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
/* Get PTE and page size from page tables */
|
2017-07-27 13:24:53 +07:00
|
|
|
ptep = find_linux_pte(pgdir, ea, &is_thp, &hugeshift);
|
2005-11-07 07:06:55 +07:00
|
|
|
if (ptep == NULL || !pte_present(*ptep)) {
|
|
|
|
DBG_LOW(" no PTE !\n");
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
2005-11-07 07:06:55 +07:00
|
|
|
}
|
|
|
|
|
2010-07-23 05:53:23 +07:00
|
|
|
/* Add _PAGE_PRESENT to the required access perm */
|
|
|
|
access |= _PAGE_PRESENT;
|
|
|
|
|
|
|
|
/* Pre-check access permissions (will be re-checked atomically
|
|
|
|
* in __hash_page_XX but this pre-check is a fast path
|
|
|
|
*/
|
2016-04-29 20:25:34 +07:00
|
|
|
if (!check_pte_access(access, pte_val(*ptep))) {
|
2010-07-23 05:53:23 +07:00
|
|
|
DBG_LOW(" no access !\n");
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
rc = 1;
|
|
|
|
goto bail;
|
2010-07-23 05:53:23 +07:00
|
|
|
}
|
|
|
|
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
if (hugeshift) {
|
2015-10-09 10:02:21 +07:00
|
|
|
if (is_thp)
|
2013-06-20 16:00:21 +07:00
|
|
|
rc = __hash_page_thp(ea, access, vsid, (pmd_t *)ptep,
|
2014-12-04 12:30:14 +07:00
|
|
|
trap, flags, ssize, psize);
|
2013-06-20 16:00:21 +07:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
else
|
|
|
|
rc = __hash_page_huge(ea, access, vsid, ptep, trap,
|
2014-12-04 12:30:14 +07:00
|
|
|
flags, ssize, hugeshift, psize);
|
2013-06-20 16:00:21 +07:00
|
|
|
#else
|
|
|
|
else {
|
|
|
|
/*
|
|
|
|
* if we have hugeshift, and is not transhuge with
|
|
|
|
* hugetlb disabled, something is really wrong.
|
|
|
|
*/
|
|
|
|
rc = 1;
|
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
#endif
|
2014-10-08 15:54:58 +07:00
|
|
|
if (current->mm == mm)
|
|
|
|
check_paca_psize(ea, mm, psize, user_region);
|
powerpc/mm: Check paca psize is up to date for huge mappings
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.
The bug is as follows:
1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa0000000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.
We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.
The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.
We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.
Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.
Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.11+]
2014-05-28 15:21:17 +07:00
|
|
|
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
goto bail;
|
|
|
|
}
|
powerpc/mm: Allow more flexible layouts for hugepage pagetables
Currently each available hugepage size uses a slightly different
pagetable layout: that is, the bottem level table of pointers to
hugepages is a different size, and may branch off from the normal page
tables at a different level. Every hugepage aware path that needs to
walk the pagetables must therefore look up the hugepage size from the
slice info first, and work out the correct way to walk the pagetables
accordingly. Future hardware is likely to add more possible hugepage
sizes, more layout options and more mess.
This patch, therefore reworks the handling of hugepage pagetables to
reduce this complexity. In the new scheme, instead of having to
consult the slice mask, pagetable walking code can check a flag in the
PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
and the entry also contains the information (eseentially hugepage
shift) necessary to then interpret that table without recourse to the
slice mask. This scheme can be extended neatly to handle multiple
levels of self-describing "special" hugepage pagetables, although for
now we assume only one level exists.
This approach means that only the pagetable allocation path needs to
know how the pagetables should be set out. All other (hugepage)
pagetable walking paths can just interpret the structure as they go.
There already was a flag bit in PGD/PUD/PMD entries for hugepage
directory pointers, but it was only used for debug. We alter that
flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
pointer (normally it would be 1 since the pointer lies in the linear
mapping). This means that asm pagetable walking can test for (and
punt on) hugepage pointers with the same test that checks for
unpopulated page directory entries (beq becomes bge), since hugepage
pointers will always be positive, and normal pointers always negative.
While we're at it, we get rid of the confusing (and grep defeating)
#defining of hugepte_shift to be the same thing as mmu_huge_psizes.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-10-27 02:24:31 +07:00
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
#ifndef CONFIG_PPC_64K_PAGES
|
|
|
|
DBG_LOW(" i-pte: %016lx\n", pte_val(*ptep));
|
|
|
|
#else
|
|
|
|
DBG_LOW(" i-pte: %016lx %016lx\n", pte_val(*ptep),
|
|
|
|
pte_val(*(ptep + PTRS_PER_PTE)));
|
|
|
|
#endif
|
|
|
|
/* Do actual hashing */
|
2007-05-08 13:27:28 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
2016-04-29 20:25:45 +07:00
|
|
|
/* If H_PAGE_4K_PFN is set, make sure this is a 4k segment */
|
|
|
|
if ((pte_val(*ptep) & H_PAGE_4K_PFN) && psize == MMU_PAGE_64K) {
|
[POWERPC] Allow drivers to map individual 4k pages to userspace
Some drivers have resources that they want to be able to map into
userspace that are 4k in size. On a kernel configured with 64k pages
we currently end up mapping the 4k we want plus another 60k of
physical address space, which could contain anything. This can
introduce security problems, for example in the case of an infiniband
adaptor where the other 60k could contain registers that some other
program is using for its communications.
This patch adds a new function, remap_4k_pfn, which drivers can use to
map a single 4k page to userspace regardless of whether the kernel is
using a 4k or a 64k page size. Like remap_pfn_range, it would
typically be called in a driver's mmap function. It only maps a
single 4k page, which on a 64k page kernel appears replicated 16 times
throughout a 64k page. On a 4k page kernel it reduces to a call to
remap_pfn_range.
The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
gets set on the linux PTE. This alters the way that __hash_page_4K
computes the real address to put in the HPTE. The RPN field of the
linux PTE becomes the 4k RPN directly rather than being interpreted as
a 64k RPN. Since the RPN field is 32 bits, this means that physical
addresses being mapped with remap_4k_pfn have to be below 2^44,
i.e. 0x100000000000.
The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
that deals with demoting a process to use 4k pages into one function
that gets called in the various different places where we need to do
that. There were some discrepancies between exactly what was done in
the various places, such as a call to spu_flush_all_slbs in one case
but not in others.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-03 18:24:02 +07:00
|
|
|
demote_segment_4k(mm, ea);
|
|
|
|
psize = MMU_PAGE_4K;
|
|
|
|
}
|
|
|
|
|
2007-05-08 13:27:27 +07:00
|
|
|
/* If this PTE is non-cacheable and we have restrictions on
|
|
|
|
* using non cacheable large pages, then we switch to 4k
|
|
|
|
*/
|
2016-04-29 20:25:38 +07:00
|
|
|
if (mmu_ci_restrictions && psize == MMU_PAGE_64K && pte_ci(*ptep)) {
|
2007-05-08 13:27:27 +07:00
|
|
|
if (user_region) {
|
|
|
|
demote_segment_4k(mm, ea);
|
|
|
|
psize = MMU_PAGE_4K;
|
|
|
|
} else if (ea < VMALLOC_END) {
|
|
|
|
/*
|
|
|
|
* some driver did a non-cacheable mapping
|
|
|
|
* in vmalloc space, so switch vmalloc
|
|
|
|
* to 4k pages
|
|
|
|
*/
|
|
|
|
printk(KERN_ALERT "Reducing vmalloc segment "
|
|
|
|
"to 4kB pages because of "
|
|
|
|
"non-cacheable mapping\n");
|
|
|
|
psize = mmu_vmalloc_psize = MMU_PAGE_4K;
|
2014-10-08 15:54:52 +07:00
|
|
|
copro_flush_all_slbs(mm);
|
2006-06-15 07:45:18 +07:00
|
|
|
}
|
2007-05-08 13:27:27 +07:00
|
|
|
}
|
powerpc/mm: Check paca psize is up to date for huge mappings
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.
The bug is as follows:
1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa0000000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.
We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.
The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.
We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.
Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.
Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.11+]
2014-05-28 15:21:17 +07:00
|
|
|
|
2015-11-29 00:09:33 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
|
|
|
|
2014-10-08 15:54:58 +07:00
|
|
|
if (current->mm == mm)
|
|
|
|
check_paca_psize(ea, mm, psize, user_region);
|
2007-05-08 13:27:27 +07:00
|
|
|
|
2015-08-07 13:19:47 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
2006-06-15 07:45:18 +07:00
|
|
|
if (psize == MMU_PAGE_64K)
|
2014-12-04 12:30:14 +07:00
|
|
|
rc = __hash_page_64K(ea, access, vsid, ptep, trap,
|
|
|
|
flags, ssize);
|
2005-11-07 07:06:55 +07:00
|
|
|
else
|
2015-08-07 13:19:47 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
{
|
2009-12-16 21:29:56 +07:00
|
|
|
int spp = subpage_protection(mm, ea);
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
if (access & spp)
|
|
|
|
rc = -2;
|
|
|
|
else
|
|
|
|
rc = __hash_page_4K(ea, access, vsid, ptep, trap,
|
2014-12-04 12:30:14 +07:00
|
|
|
flags, ssize, spp);
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
}
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2010-07-23 07:31:13 +07:00
|
|
|
/* Dump some info in case of hash insertion failure, they should
|
|
|
|
* never happen so it is really useful to know if/when they do
|
|
|
|
*/
|
|
|
|
if (rc == -1)
|
|
|
|
hash_failure_debug(ea, access, vsid, trap, ssize, psize,
|
2013-04-28 16:37:37 +07:00
|
|
|
psize, pte_val(*ptep));
|
2005-11-07 07:06:55 +07:00
|
|
|
#ifndef CONFIG_PPC_64K_PAGES
|
|
|
|
DBG_LOW(" o-pte: %016lx\n", pte_val(*ptep));
|
|
|
|
#else
|
|
|
|
DBG_LOW(" o-pte: %016lx %016lx\n", pte_val(*ptep),
|
|
|
|
pte_val(*(ptep + PTRS_PER_PTE)));
|
|
|
|
#endif
|
|
|
|
DBG_LOW(" -> rc=%d\n", rc);
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
|
|
|
|
bail:
|
|
|
|
exception_exit(prev_state);
|
2005-11-07 07:06:55 +07:00
|
|
|
return rc;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2014-10-08 15:54:58 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hash_page_mm);
|
|
|
|
|
2014-12-04 12:30:14 +07:00
|
|
|
int hash_page(unsigned long ea, unsigned long access, unsigned long trap,
|
|
|
|
unsigned long dsisr)
|
2014-10-08 15:54:58 +07:00
|
|
|
{
|
2014-12-04 12:30:14 +07:00
|
|
|
unsigned long flags = 0;
|
2014-10-08 15:54:58 +07:00
|
|
|
struct mm_struct *mm = current->mm;
|
|
|
|
|
|
|
|
if (REGION_ID(ea) == VMALLOC_REGION_ID)
|
|
|
|
mm = &init_mm;
|
|
|
|
|
2014-12-04 12:30:14 +07:00
|
|
|
if (dsisr & DSISR_NOHPTE)
|
|
|
|
flags |= HPTE_NOHPTE_UPDATE;
|
|
|
|
|
|
|
|
return hash_page_mm(mm, ea, access, trap, flags);
|
2014-10-08 15:54:58 +07:00
|
|
|
}
|
2005-11-16 03:53:48 +07:00
|
|
|
EXPORT_SYMBOL_GPL(hash_page);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2015-12-01 10:36:44 +07:00
|
|
|
int __hash_page(unsigned long ea, unsigned long msr, unsigned long trap,
|
|
|
|
unsigned long dsisr)
|
|
|
|
{
|
2016-04-29 20:25:30 +07:00
|
|
|
unsigned long access = _PAGE_PRESENT | _PAGE_READ;
|
2015-12-01 10:36:44 +07:00
|
|
|
unsigned long flags = 0;
|
|
|
|
struct mm_struct *mm = current->mm;
|
|
|
|
|
|
|
|
if (REGION_ID(ea) == VMALLOC_REGION_ID)
|
|
|
|
mm = &init_mm;
|
|
|
|
|
|
|
|
if (dsisr & DSISR_NOHPTE)
|
|
|
|
flags |= HPTE_NOHPTE_UPDATE;
|
|
|
|
|
|
|
|
if (dsisr & DSISR_ISSTORE)
|
2016-04-29 20:25:30 +07:00
|
|
|
access |= _PAGE_WRITE;
|
2015-12-01 10:36:44 +07:00
|
|
|
/*
|
2016-04-29 20:25:34 +07:00
|
|
|
* We set _PAGE_PRIVILEGED only when
|
|
|
|
* kernel mode access kernel space.
|
|
|
|
*
|
|
|
|
* _PAGE_PRIVILEGED is NOT set
|
|
|
|
* 1) when kernel mode access user space
|
|
|
|
* 2) user space access kernel space.
|
2015-12-01 10:36:44 +07:00
|
|
|
*/
|
2016-04-29 20:25:34 +07:00
|
|
|
access |= _PAGE_PRIVILEGED;
|
2015-12-01 10:36:44 +07:00
|
|
|
if ((msr & MSR_PR) || (REGION_ID(ea) == USER_REGION_ID))
|
2016-04-29 20:25:34 +07:00
|
|
|
access &= ~_PAGE_PRIVILEGED;
|
2015-12-01 10:36:44 +07:00
|
|
|
|
|
|
|
if (trap == 0x400)
|
|
|
|
access |= _PAGE_EXEC;
|
|
|
|
|
|
|
|
return hash_page_mm(mm, ea, access, trap, flags);
|
|
|
|
}
|
|
|
|
|
2016-05-06 13:46:00 +07:00
|
|
|
#ifdef CONFIG_PPC_MM_SLICES
|
|
|
|
static bool should_hash_preload(struct mm_struct *mm, unsigned long ea)
|
|
|
|
{
|
powerpc/mm/hash64: Fix subpage protection with 4K HPTE config
With Linux page size of 64K and hardware only supporting 4K HPTE, if we
use subpage protection, we always fail for the subpage 0 as shown
below (using the selftest subpage_prot test):
520175565: (4520111850): Failed at 0x3fffad4b0000 (p=13,sp=0,w=0), want=fault, got=pass !
4520890210: (4520826495): Failed at 0x3fffad5b0000 (p=29,sp=0,w=0), want=fault, got=pass !
4521574251: (4521510536): Failed at 0x3fffad6b0000 (p=45,sp=0,w=0), want=fault, got=pass !
4522258324: (4522194609): Failed at 0x3fffad7b0000 (p=61,sp=0,w=0), want=fault, got=pass !
This is because hash preload wrongly inserts the HPTE entry for subpage
0 without looking at the subpage protection information.
Fix it by teaching should_hash_preload() not to preload if we have
subpage protection configured for that range.
It appears this has been broken since it was introduced in 2008.
Fixes: fa28237cfcc5 ("[POWERPC] Provide a way to protect 4k subpages when using 64k pages")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
[mpe: Rework into should_hash_preload() to avoid build fails w/SLICES=n]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-05-06 13:47:12 +07:00
|
|
|
int psize = get_slice_psize(mm, ea);
|
|
|
|
|
2016-05-06 13:46:00 +07:00
|
|
|
/* We only prefault standard pages for now */
|
powerpc/mm/hash64: Fix subpage protection with 4K HPTE config
With Linux page size of 64K and hardware only supporting 4K HPTE, if we
use subpage protection, we always fail for the subpage 0 as shown
below (using the selftest subpage_prot test):
520175565: (4520111850): Failed at 0x3fffad4b0000 (p=13,sp=0,w=0), want=fault, got=pass !
4520890210: (4520826495): Failed at 0x3fffad5b0000 (p=29,sp=0,w=0), want=fault, got=pass !
4521574251: (4521510536): Failed at 0x3fffad6b0000 (p=45,sp=0,w=0), want=fault, got=pass !
4522258324: (4522194609): Failed at 0x3fffad7b0000 (p=61,sp=0,w=0), want=fault, got=pass !
This is because hash preload wrongly inserts the HPTE entry for subpage
0 without looking at the subpage protection information.
Fix it by teaching should_hash_preload() not to preload if we have
subpage protection configured for that range.
It appears this has been broken since it was introduced in 2008.
Fixes: fa28237cfcc5 ("[POWERPC] Provide a way to protect 4k subpages when using 64k pages")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
[mpe: Rework into should_hash_preload() to avoid build fails w/SLICES=n]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-05-06 13:47:12 +07:00
|
|
|
if (unlikely(psize != mm->context.user_psize))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't prefault if subpage protection is enabled for the EA.
|
|
|
|
*/
|
|
|
|
if (unlikely((psize == MMU_PAGE_4K) && subpage_protection(mm, ea)))
|
2016-05-06 13:46:00 +07:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static bool should_hash_preload(struct mm_struct *mm, unsigned long ea)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-11-07 07:06:55 +07:00
|
|
|
void hash_preload(struct mm_struct *mm, unsigned long ea,
|
|
|
|
unsigned long access, unsigned long trap)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-06-20 16:00:18 +07:00
|
|
|
int hugepage_shift;
|
2005-11-07 07:06:55 +07:00
|
|
|
unsigned long vsid;
|
2010-11-18 01:52:45 +07:00
|
|
|
pgd_t *pgdir;
|
2005-11-07 07:06:55 +07:00
|
|
|
pte_t *ptep;
|
|
|
|
unsigned long flags;
|
2014-12-04 12:30:14 +07:00
|
|
|
int rc, ssize, update_flags = 0;
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2007-05-08 13:27:27 +07:00
|
|
|
BUG_ON(REGION_ID(ea) != USER_REGION_ID);
|
|
|
|
|
2016-05-06 13:46:00 +07:00
|
|
|
if (!should_hash_preload(mm, ea))
|
2005-11-07 07:06:55 +07:00
|
|
|
return;
|
|
|
|
|
|
|
|
DBG_LOW("hash_preload(mm=%p, mm->pgdir=%p, ea=%016lx, access=%lx,"
|
|
|
|
" trap=%lx\n", mm, mm->pgd, ea, access, trap);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2007-05-08 13:27:27 +07:00
|
|
|
/* Get Linux PTE if available */
|
2005-11-07 07:06:55 +07:00
|
|
|
pgdir = mm->pgd;
|
|
|
|
if (pgdir == NULL)
|
|
|
|
return;
|
2013-06-20 16:00:22 +07:00
|
|
|
|
|
|
|
/* Get VSID */
|
|
|
|
ssize = user_segment_size(ea);
|
|
|
|
vsid = get_vsid(mm->context.id, ea, ssize);
|
|
|
|
if (!vsid)
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* Hash doesn't like irqs. Walking linux page table with irq disabled
|
|
|
|
* saves us from holding multiple locks.
|
|
|
|
*/
|
|
|
|
local_irq_save(flags);
|
|
|
|
|
2013-06-20 16:00:18 +07:00
|
|
|
/*
|
|
|
|
* THP pages use update_mmu_cache_pmd. We don't do
|
|
|
|
* hash preload there. Hence can ignore THP here
|
|
|
|
*/
|
2017-07-27 13:24:53 +07:00
|
|
|
ptep = find_current_mm_pte(pgdir, ea, NULL, &hugepage_shift);
|
2005-11-07 07:06:55 +07:00
|
|
|
if (!ptep)
|
2013-06-20 16:00:22 +07:00
|
|
|
goto out_exit;
|
2007-05-08 13:27:27 +07:00
|
|
|
|
2013-06-20 16:00:18 +07:00
|
|
|
WARN_ON(hugepage_shift);
|
2007-05-08 13:27:27 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
2016-04-29 20:25:45 +07:00
|
|
|
/* If either H_PAGE_4K_PFN or cache inhibited is set (and we are on
|
2007-05-08 13:27:27 +07:00
|
|
|
* a 64K kernel), then we don't preload, hash_page() will take
|
|
|
|
* care of it once we actually try to access the page.
|
|
|
|
* That way we don't have to duplicate all of the logic for segment
|
|
|
|
* page size demotion here
|
|
|
|
*/
|
2016-04-29 20:25:45 +07:00
|
|
|
if ((pte_val(*ptep) & H_PAGE_4K_PFN) || pte_ci(*ptep))
|
2013-06-20 16:00:22 +07:00
|
|
|
goto out_exit;
|
2007-05-08 13:27:27 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
|
|
|
|
2007-05-08 13:27:28 +07:00
|
|
|
/* Is that local to this CPU ? */
|
2017-07-24 11:28:01 +07:00
|
|
|
if (mm_is_thread_local(mm))
|
2014-12-04 12:30:14 +07:00
|
|
|
update_flags |= HPTE_LOCAL_UPDATE;
|
2007-05-08 13:27:28 +07:00
|
|
|
|
|
|
|
/* Hash it in */
|
2015-08-07 13:19:47 +07:00
|
|
|
#ifdef CONFIG_PPC_64K_PAGES
|
2006-06-15 07:45:18 +07:00
|
|
|
if (mm->context.user_psize == MMU_PAGE_64K)
|
2014-12-04 12:30:14 +07:00
|
|
|
rc = __hash_page_64K(ea, access, vsid, ptep, trap,
|
|
|
|
update_flags, ssize);
|
2005-04-17 05:20:36 +07:00
|
|
|
else
|
2015-08-07 13:19:47 +07:00
|
|
|
#endif /* CONFIG_PPC_64K_PAGES */
|
2014-12-04 12:30:14 +07:00
|
|
|
rc = __hash_page_4K(ea, access, vsid, ptep, trap, update_flags,
|
|
|
|
ssize, subpage_protection(mm, ea));
|
2010-07-23 07:31:13 +07:00
|
|
|
|
|
|
|
/* Dump some info in case of hash insertion failure, they should
|
|
|
|
* never happen so it is really useful to know if/when they do
|
|
|
|
*/
|
|
|
|
if (rc == -1)
|
|
|
|
hash_failure_debug(ea, access, vsid, trap, ssize,
|
2013-04-28 16:37:37 +07:00
|
|
|
mm->context.user_psize,
|
|
|
|
mm->context.user_psize,
|
|
|
|
pte_val(*ptep));
|
2013-06-20 16:00:22 +07:00
|
|
|
out_exit:
|
2005-11-07 07:06:55 +07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2018-01-19 08:50:41 +07:00
|
|
|
#ifdef CONFIG_PPC_MEM_KEYS
|
|
|
|
/*
|
|
|
|
* Return the protection key associated with the given address and the
|
|
|
|
* mm_struct.
|
|
|
|
*/
|
|
|
|
u16 get_mm_addr_key(struct mm_struct *mm, unsigned long address)
|
|
|
|
{
|
|
|
|
pte_t *ptep;
|
|
|
|
u16 pkey = 0;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (!mm || !mm->pgd)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
ptep = find_linux_pte(mm->pgd, address, NULL, NULL);
|
|
|
|
if (ptep)
|
|
|
|
pkey = pte_to_pkey_bits(pte_val(READ_ONCE(*ptep)));
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
|
|
|
return pkey;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PPC_MEM_KEYS */
|
|
|
|
|
2016-09-02 13:17:26 +07:00
|
|
|
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
|
|
|
|
static inline void tm_flush_hash_page(int local)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Transactions are not aborted by tlbiel, only tlbie. Without, syncing a
|
|
|
|
* page back to a block device w/PIO could pick up transactional data
|
|
|
|
* (bad!) so we force an abort here. Before the sync the page will be
|
|
|
|
* made read-only, which will flush_hash_page. BIG ISSUE here: if the
|
|
|
|
* kernel uses a page from userspace without unmapping it first, it may
|
|
|
|
* see the speculated version.
|
|
|
|
*/
|
|
|
|
if (local && cpu_has_feature(CPU_FTR_TM) && current->thread.regs &&
|
|
|
|
MSR_TM_ACTIVE(current->thread.regs->msr)) {
|
|
|
|
tm_enable();
|
|
|
|
tm_abort(TM_CAUSE_TLBI);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void tm_flush_hash_page(int local)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-11-06 15:50:46 +07:00
|
|
|
/*
|
|
|
|
* Return the global hash slot, corresponding to the given PTE, which contains
|
|
|
|
* the HPTE.
|
|
|
|
*/
|
|
|
|
unsigned long pte_get_hash_gslot(unsigned long vpn, unsigned long shift,
|
|
|
|
int ssize, real_pte_t rpte, unsigned int subpg_index)
|
|
|
|
{
|
|
|
|
unsigned long hash, gslot, hidx;
|
|
|
|
|
|
|
|
hash = hpt_hash(vpn, shift, ssize);
|
|
|
|
hidx = __rpte_to_hidx(rpte, subpg_index);
|
|
|
|
if (hidx & _PTEIDX_SECONDARY)
|
|
|
|
hash = ~hash;
|
|
|
|
gslot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
|
|
|
|
gslot += hidx & _PTEIDX_GROUP_IX;
|
|
|
|
return gslot;
|
|
|
|
}
|
|
|
|
|
2007-10-29 08:05:18 +07:00
|
|
|
/* WARNING: This is called from hash_low_64.S, if you change this prototype,
|
|
|
|
* do not forget to update the assembly call site !
|
|
|
|
*/
|
2012-09-10 09:52:50 +07:00
|
|
|
void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize, int ssize,
|
2014-12-04 12:30:14 +07:00
|
|
|
unsigned long flags)
|
2005-11-07 07:06:55 +07:00
|
|
|
{
|
2017-11-06 15:50:51 +07:00
|
|
|
unsigned long index, shift, gslot;
|
2014-12-04 12:30:14 +07:00
|
|
|
int local = flags & HPTE_LOCAL_UPDATE;
|
2005-11-07 07:06:55 +07:00
|
|
|
|
2012-09-10 09:52:50 +07:00
|
|
|
DBG_LOW("flush_hash_page(vpn=%016lx)\n", vpn);
|
|
|
|
pte_iterate_hashed_subpages(pte, psize, vpn, index, shift) {
|
2017-11-06 15:50:51 +07:00
|
|
|
gslot = pte_get_hash_gslot(vpn, shift, ssize, pte, index);
|
|
|
|
DBG_LOW(" sub %ld: gslot=%lx\n", index, gslot);
|
2013-06-20 16:00:13 +07:00
|
|
|
/*
|
|
|
|
* We use same base page size and actual psize, because we don't
|
|
|
|
* use these functions for hugepage
|
|
|
|
*/
|
2017-11-06 15:50:51 +07:00
|
|
|
mmu_hash_ops.hpte_invalidate(gslot, vpn, psize, psize,
|
2016-07-05 12:03:58 +07:00
|
|
|
ssize, local);
|
2005-11-07 07:06:55 +07:00
|
|
|
} pte_iterate_hashed_end();
|
2013-02-13 23:21:40 +07:00
|
|
|
|
2016-09-02 13:17:26 +07:00
|
|
|
tm_flush_hash_page(local);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2014-11-02 22:45:27 +07:00
|
|
|
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
|
|
|
|
void flush_hash_hugepage(unsigned long vsid, unsigned long addr,
|
2014-12-04 12:30:14 +07:00
|
|
|
pmd_t *pmdp, unsigned int psize, int ssize,
|
|
|
|
unsigned long flags)
|
2014-11-02 22:45:27 +07:00
|
|
|
{
|
|
|
|
int i, max_hpte_count, valid;
|
|
|
|
unsigned long s_addr;
|
|
|
|
unsigned char *hpte_slot_array;
|
|
|
|
unsigned long hidx, shift, vpn, hash, slot;
|
2014-12-04 12:30:14 +07:00
|
|
|
int local = flags & HPTE_LOCAL_UPDATE;
|
2014-11-02 22:45:27 +07:00
|
|
|
|
|
|
|
s_addr = addr & HPAGE_PMD_MASK;
|
|
|
|
hpte_slot_array = get_hpte_slot_array(pmdp);
|
|
|
|
/*
|
|
|
|
* IF we try to do a HUGE PTE update after a withdraw is done.
|
|
|
|
* we will find the below NULL. This happens when we do
|
|
|
|
* split_huge_page_pmd
|
|
|
|
*/
|
|
|
|
if (!hpte_slot_array)
|
|
|
|
return;
|
|
|
|
|
2016-07-05 12:03:58 +07:00
|
|
|
if (mmu_hash_ops.hugepage_invalidate) {
|
|
|
|
mmu_hash_ops.hugepage_invalidate(vsid, s_addr, hpte_slot_array,
|
|
|
|
psize, ssize, local);
|
2014-11-02 22:45:28 +07:00
|
|
|
goto tm_abort;
|
|
|
|
}
|
2014-11-02 22:45:27 +07:00
|
|
|
/*
|
|
|
|
* No bluk hpte removal support, invalidate each entry
|
|
|
|
*/
|
|
|
|
shift = mmu_psize_defs[psize].shift;
|
|
|
|
max_hpte_count = HPAGE_PMD_SIZE >> shift;
|
|
|
|
for (i = 0; i < max_hpte_count; i++) {
|
|
|
|
/*
|
|
|
|
* 8 bits per each hpte entries
|
|
|
|
* 000| [ secondary group (one bit) | hidx (3 bits) | valid bit]
|
|
|
|
*/
|
|
|
|
valid = hpte_valid(hpte_slot_array, i);
|
|
|
|
if (!valid)
|
|
|
|
continue;
|
|
|
|
hidx = hpte_hash_index(hpte_slot_array, i);
|
|
|
|
|
|
|
|
/* get the vpn */
|
|
|
|
addr = s_addr + (i * (1ul << shift));
|
|
|
|
vpn = hpt_vpn(addr, vsid, ssize);
|
|
|
|
hash = hpt_hash(vpn, shift, ssize);
|
|
|
|
if (hidx & _PTEIDX_SECONDARY)
|
|
|
|
hash = ~hash;
|
|
|
|
|
|
|
|
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
|
|
|
|
slot += hidx & _PTEIDX_GROUP_IX;
|
2016-07-05 12:03:58 +07:00
|
|
|
mmu_hash_ops.hpte_invalidate(slot, vpn, psize,
|
|
|
|
MMU_PAGE_16M, ssize, local);
|
2014-11-02 22:45:28 +07:00
|
|
|
}
|
|
|
|
tm_abort:
|
2016-09-02 13:17:26 +07:00
|
|
|
tm_flush_hash_page(local);
|
2014-11-02 22:45:27 +07:00
|
|
|
}
|
|
|
|
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
|
|
|
|
|
2005-09-20 10:52:50 +07:00
|
|
|
void flush_hash_range(unsigned long number, int local)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2016-07-05 12:03:58 +07:00
|
|
|
if (mmu_hash_ops.flush_hash_range)
|
|
|
|
mmu_hash_ops.flush_hash_range(number, local);
|
2005-11-07 07:06:55 +07:00
|
|
|
else {
|
2005-04-17 05:20:36 +07:00
|
|
|
int i;
|
2005-09-20 10:52:50 +07:00
|
|
|
struct ppc64_tlb_batch *batch =
|
powerpc: Replace __get_cpu_var uses
This still has not been merged and now powerpc is the only arch that does
not have this change. Sorry about missing linuxppc-dev before.
V2->V2
- Fix up to work against 3.18-rc1
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
__this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
__this_cpu_inc(y)
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
Signed-off-by: Christoph Lameter <cl@linux.com>
[mpe: Fix build errors caused by set/or_softirq_pending(), and rework
assignment in __set_breakpoint() to use memcpy().]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-10-22 03:23:25 +07:00
|
|
|
this_cpu_ptr(&ppc64_tlb_batch);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
for (i = 0; i < number; i++)
|
2012-09-10 09:52:50 +07:00
|
|
|
flush_hash_page(batch->vpn[i], batch->pte[i],
|
2007-10-11 17:37:10 +07:00
|
|
|
batch->psize, batch->ssize, local);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* low_hash_fault is called when we the low level hash code failed
|
|
|
|
* to instert a PTE due to an hypervisor error
|
|
|
|
*/
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
void low_hash_fault(struct pt_regs *regs, unsigned long address, int rc)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
enum ctx_state prev_state = exception_enter();
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
if (user_mode(regs)) {
|
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-24 04:35:13 +07:00
|
|
|
#ifdef CONFIG_PPC_SUBPAGE_PROT
|
|
|
|
if (rc == -2)
|
|
|
|
_exception(SIGSEGV, regs, SEGV_ACCERR, address);
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
_exception(SIGBUS, regs, BUS_ADRERR, address);
|
|
|
|
} else
|
|
|
|
bad_page_fault(regs, address, SIGBUS);
|
powerpc: Exception hooks for context tracking subsystem
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
But after the exception handling moved to generic code, and some changes in
following two commits:
56dd9470d7c8734f055da2a6bac553caf4a468eb
context_tracking: Move exception handling to generic code
6c1e0256fad84a843d915414e4b5973b7443d48d
context_tracking: Restore correct previous context state on exception exit
it is able for exception hooks to use the generic code above instead of a
redundant arch implementation.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-13 23:16:41 +07:00
|
|
|
|
|
|
|
exception_exit(prev_state);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2007-04-12 12:30:23 +07:00
|
|
|
|
2013-04-15 23:53:19 +07:00
|
|
|
long hpte_insert_repeating(unsigned long hash, unsigned long vpn,
|
|
|
|
unsigned long pa, unsigned long rflags,
|
|
|
|
unsigned long vflags, int psize, int ssize)
|
|
|
|
{
|
|
|
|
unsigned long hpte_group;
|
|
|
|
long slot;
|
|
|
|
|
|
|
|
repeat:
|
|
|
|
hpte_group = ((hash & htab_hash_mask) *
|
|
|
|
HPTES_PER_GROUP) & ~0x7UL;
|
|
|
|
|
|
|
|
/* Insert into the hash table, primary slot */
|
2016-07-05 12:03:58 +07:00
|
|
|
slot = mmu_hash_ops.hpte_insert(hpte_group, vpn, pa, rflags, vflags,
|
|
|
|
psize, psize, ssize);
|
2013-04-15 23:53:19 +07:00
|
|
|
|
|
|
|
/* Primary is full, try the secondary */
|
|
|
|
if (unlikely(slot == -1)) {
|
|
|
|
hpte_group = ((~hash & htab_hash_mask) *
|
|
|
|
HPTES_PER_GROUP) & ~0x7UL;
|
2016-07-05 12:03:58 +07:00
|
|
|
slot = mmu_hash_ops.hpte_insert(hpte_group, vpn, pa, rflags,
|
|
|
|
vflags | HPTE_V_SECONDARY,
|
|
|
|
psize, psize, ssize);
|
2013-04-15 23:53:19 +07:00
|
|
|
if (slot == -1) {
|
|
|
|
if (mftb() & 0x1)
|
|
|
|
hpte_group = ((hash & htab_hash_mask) *
|
|
|
|
HPTES_PER_GROUP)&~0x7UL;
|
|
|
|
|
2016-07-05 12:03:58 +07:00
|
|
|
mmu_hash_ops.hpte_remove(hpte_group);
|
2013-04-15 23:53:19 +07:00
|
|
|
goto repeat;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return slot;
|
|
|
|
}
|
|
|
|
|
2007-04-12 12:30:23 +07:00
|
|
|
#ifdef CONFIG_DEBUG_PAGEALLOC
|
|
|
|
static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
|
|
|
|
{
|
powerpc: Try to insert the hptes repeatedly in kernel_map_linear_page()
This patch fixes the following oops, which could be trigged by build the kernel
with many concurrent threads, under CONFIG_DEBUG_PAGEALLOC.
hpte_insert() might return -1, indicating that the bucket (primary here)
is full. We are not necessarily reporting a BUG in this case. Instead, we could
try repeatedly (try secondary, remove and try again) until we find a slot.
[ 543.075675] ------------[ cut here ]------------
[ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
[ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
[ 543.075722] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 543.075741] Modules linked in: binfmt_misc ehea
[ 543.075759] NIP: c000000000036eb0 LR: c000000000036ea4 CTR: c00000000005a594
[ 543.075771] REGS: c0000000a90832c0 TRAP: 0700 Not tainted (3.8.0-next-20130222)
[ 543.075781] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 22224482 XER: 00000000
[ 543.075816] SOFTE: 0
[ 543.075823] CFAR: c00000000004c200
[ 543.075830] TASK = c0000000e506b750[23934] 'cc1' THREAD: c0000000a9080000 CPU: 1
GPR00: 0000000000000001 c0000000a9083540 c000000000c600a8 ffffffffffffffff
GPR04: 0000000000000050 fffffffffffffffa c0000000a90834e0 00000000004ff594
GPR08: 0000000000000001 0000000000000000 000000009592d4d8 c000000000c86854
GPR12: 0000000000000002 c000000006ead300 0000000000a51000 0000000000000001
GPR16: f000000003354380 ffffffffffffffff ffffffffffffff80 0000000000000000
GPR20: 0000000000000001 c000000000c600a8 0000000000000001 0000000000000001
GPR24: 0000000003354380 c000000000000000 0000000000000000 c000000000b65950
GPR28: 0000002000000000 00000000000cd50e 0000000000bf50d9 c000000000c7c230
[ 543.076005] NIP [c000000000036eb0] .kernel_map_pages+0x1e0/0x3f8
[ 543.076016] LR [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8
[ 543.076025] Call Trace:
[ 543.076033] [c0000000a9083540] [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8 (unreliable)
[ 543.076053] [c0000000a9083640] [c000000000167638] .get_page_from_freelist+0x6cc/0x8dc
[ 543.076067] [c0000000a9083800] [c000000000167a48] .__alloc_pages_nodemask+0x200/0x96c
[ 543.076082] [c0000000a90839c0] [c0000000001ade44] .alloc_pages_vma+0x160/0x1e4
[ 543.076098] [c0000000a9083a80] [c00000000018ce04] .handle_pte_fault+0x1b0/0x7e8
[ 543.076113] [c0000000a9083b50] [c00000000018d5a8] .handle_mm_fault+0x16c/0x1a0
[ 543.076129] [c0000000a9083c00] [c0000000007bf1dc] .do_page_fault+0x4d0/0x7a4
[ 543.076144] [c0000000a9083e30] [c0000000000090e8] handle_page_fault+0x10/0x30
[ 543.076155] Instruction dump:
[ 543.076163] 7c630038 78631d88 e80a0000 f8410028 7c0903a6 e91f01de e96a0010 e84a0008
[ 543.076192] 4e800421 e8410028 7c7107b4 7a200fe0 <0b000000> 7f63db78 48785781 60000000
[ 543.076224] ---[ end trace bd5807e8d6ae186b ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
2013-04-15 23:53:20 +07:00
|
|
|
unsigned long hash;
|
2007-10-11 17:37:10 +07:00
|
|
|
unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize);
|
2012-09-10 09:52:50 +07:00
|
|
|
unsigned long vpn = hpt_vpn(vaddr, vsid, mmu_kernel_ssize);
|
2015-06-01 18:11:35 +07:00
|
|
|
unsigned long mode = htab_convert_pte_flags(pgprot_val(PAGE_KERNEL));
|
powerpc: Try to insert the hptes repeatedly in kernel_map_linear_page()
This patch fixes the following oops, which could be trigged by build the kernel
with many concurrent threads, under CONFIG_DEBUG_PAGEALLOC.
hpte_insert() might return -1, indicating that the bucket (primary here)
is full. We are not necessarily reporting a BUG in this case. Instead, we could
try repeatedly (try secondary, remove and try again) until we find a slot.
[ 543.075675] ------------[ cut here ]------------
[ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
[ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
[ 543.075722] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 543.075741] Modules linked in: binfmt_misc ehea
[ 543.075759] NIP: c000000000036eb0 LR: c000000000036ea4 CTR: c00000000005a594
[ 543.075771] REGS: c0000000a90832c0 TRAP: 0700 Not tainted (3.8.0-next-20130222)
[ 543.075781] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 22224482 XER: 00000000
[ 543.075816] SOFTE: 0
[ 543.075823] CFAR: c00000000004c200
[ 543.075830] TASK = c0000000e506b750[23934] 'cc1' THREAD: c0000000a9080000 CPU: 1
GPR00: 0000000000000001 c0000000a9083540 c000000000c600a8 ffffffffffffffff
GPR04: 0000000000000050 fffffffffffffffa c0000000a90834e0 00000000004ff594
GPR08: 0000000000000001 0000000000000000 000000009592d4d8 c000000000c86854
GPR12: 0000000000000002 c000000006ead300 0000000000a51000 0000000000000001
GPR16: f000000003354380 ffffffffffffffff ffffffffffffff80 0000000000000000
GPR20: 0000000000000001 c000000000c600a8 0000000000000001 0000000000000001
GPR24: 0000000003354380 c000000000000000 0000000000000000 c000000000b65950
GPR28: 0000002000000000 00000000000cd50e 0000000000bf50d9 c000000000c7c230
[ 543.076005] NIP [c000000000036eb0] .kernel_map_pages+0x1e0/0x3f8
[ 543.076016] LR [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8
[ 543.076025] Call Trace:
[ 543.076033] [c0000000a9083540] [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8 (unreliable)
[ 543.076053] [c0000000a9083640] [c000000000167638] .get_page_from_freelist+0x6cc/0x8dc
[ 543.076067] [c0000000a9083800] [c000000000167a48] .__alloc_pages_nodemask+0x200/0x96c
[ 543.076082] [c0000000a90839c0] [c0000000001ade44] .alloc_pages_vma+0x160/0x1e4
[ 543.076098] [c0000000a9083a80] [c00000000018ce04] .handle_pte_fault+0x1b0/0x7e8
[ 543.076113] [c0000000a9083b50] [c00000000018d5a8] .handle_mm_fault+0x16c/0x1a0
[ 543.076129] [c0000000a9083c00] [c0000000007bf1dc] .do_page_fault+0x4d0/0x7a4
[ 543.076144] [c0000000a9083e30] [c0000000000090e8] handle_page_fault+0x10/0x30
[ 543.076155] Instruction dump:
[ 543.076163] 7c630038 78631d88 e80a0000 f8410028 7c0903a6 e91f01de e96a0010 e84a0008
[ 543.076192] 4e800421 e8410028 7c7107b4 7a200fe0 <0b000000> 7f63db78 48785781 60000000
[ 543.076224] ---[ end trace bd5807e8d6ae186b ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
2013-04-15 23:53:20 +07:00
|
|
|
long ret;
|
2007-04-12 12:30:23 +07:00
|
|
|
|
2012-09-10 09:52:50 +07:00
|
|
|
hash = hpt_hash(vpn, PAGE_SHIFT, mmu_kernel_ssize);
|
2007-04-12 12:30:23 +07:00
|
|
|
|
2013-03-13 10:34:54 +07:00
|
|
|
/* Don't create HPTE entries for bad address */
|
|
|
|
if (!vsid)
|
|
|
|
return;
|
powerpc: Try to insert the hptes repeatedly in kernel_map_linear_page()
This patch fixes the following oops, which could be trigged by build the kernel
with many concurrent threads, under CONFIG_DEBUG_PAGEALLOC.
hpte_insert() might return -1, indicating that the bucket (primary here)
is full. We are not necessarily reporting a BUG in this case. Instead, we could
try repeatedly (try secondary, remove and try again) until we find a slot.
[ 543.075675] ------------[ cut here ]------------
[ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
[ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
[ 543.075722] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 543.075741] Modules linked in: binfmt_misc ehea
[ 543.075759] NIP: c000000000036eb0 LR: c000000000036ea4 CTR: c00000000005a594
[ 543.075771] REGS: c0000000a90832c0 TRAP: 0700 Not tainted (3.8.0-next-20130222)
[ 543.075781] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 22224482 XER: 00000000
[ 543.075816] SOFTE: 0
[ 543.075823] CFAR: c00000000004c200
[ 543.075830] TASK = c0000000e506b750[23934] 'cc1' THREAD: c0000000a9080000 CPU: 1
GPR00: 0000000000000001 c0000000a9083540 c000000000c600a8 ffffffffffffffff
GPR04: 0000000000000050 fffffffffffffffa c0000000a90834e0 00000000004ff594
GPR08: 0000000000000001 0000000000000000 000000009592d4d8 c000000000c86854
GPR12: 0000000000000002 c000000006ead300 0000000000a51000 0000000000000001
GPR16: f000000003354380 ffffffffffffffff ffffffffffffff80 0000000000000000
GPR20: 0000000000000001 c000000000c600a8 0000000000000001 0000000000000001
GPR24: 0000000003354380 c000000000000000 0000000000000000 c000000000b65950
GPR28: 0000002000000000 00000000000cd50e 0000000000bf50d9 c000000000c7c230
[ 543.076005] NIP [c000000000036eb0] .kernel_map_pages+0x1e0/0x3f8
[ 543.076016] LR [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8
[ 543.076025] Call Trace:
[ 543.076033] [c0000000a9083540] [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8 (unreliable)
[ 543.076053] [c0000000a9083640] [c000000000167638] .get_page_from_freelist+0x6cc/0x8dc
[ 543.076067] [c0000000a9083800] [c000000000167a48] .__alloc_pages_nodemask+0x200/0x96c
[ 543.076082] [c0000000a90839c0] [c0000000001ade44] .alloc_pages_vma+0x160/0x1e4
[ 543.076098] [c0000000a9083a80] [c00000000018ce04] .handle_pte_fault+0x1b0/0x7e8
[ 543.076113] [c0000000a9083b50] [c00000000018d5a8] .handle_mm_fault+0x16c/0x1a0
[ 543.076129] [c0000000a9083c00] [c0000000007bf1dc] .do_page_fault+0x4d0/0x7a4
[ 543.076144] [c0000000a9083e30] [c0000000000090e8] handle_page_fault+0x10/0x30
[ 543.076155] Instruction dump:
[ 543.076163] 7c630038 78631d88 e80a0000 f8410028 7c0903a6 e91f01de e96a0010 e84a0008
[ 543.076192] 4e800421 e8410028 7c7107b4 7a200fe0 <0b000000> 7f63db78 48785781 60000000
[ 543.076224] ---[ end trace bd5807e8d6ae186b ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
2013-04-15 23:53:20 +07:00
|
|
|
|
|
|
|
ret = hpte_insert_repeating(hash, vpn, __pa(vaddr), mode,
|
|
|
|
HPTE_V_BOLTED,
|
|
|
|
mmu_linear_psize, mmu_kernel_ssize);
|
|
|
|
|
2007-04-12 12:30:23 +07:00
|
|
|
BUG_ON (ret < 0);
|
|
|
|
spin_lock(&linear_map_hash_lock);
|
|
|
|
BUG_ON(linear_map_hash_slots[lmi] & 0x80);
|
|
|
|
linear_map_hash_slots[lmi] = ret | 0x80;
|
|
|
|
spin_unlock(&linear_map_hash_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kernel_unmap_linear_page(unsigned long vaddr, unsigned long lmi)
|
|
|
|
{
|
2007-10-11 17:37:10 +07:00
|
|
|
unsigned long hash, hidx, slot;
|
|
|
|
unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize);
|
2012-09-10 09:52:50 +07:00
|
|
|
unsigned long vpn = hpt_vpn(vaddr, vsid, mmu_kernel_ssize);
|
2007-04-12 12:30:23 +07:00
|
|
|
|
2012-09-10 09:52:50 +07:00
|
|
|
hash = hpt_hash(vpn, PAGE_SHIFT, mmu_kernel_ssize);
|
2007-04-12 12:30:23 +07:00
|
|
|
spin_lock(&linear_map_hash_lock);
|
|
|
|
BUG_ON(!(linear_map_hash_slots[lmi] & 0x80));
|
|
|
|
hidx = linear_map_hash_slots[lmi] & 0x7f;
|
|
|
|
linear_map_hash_slots[lmi] = 0;
|
|
|
|
spin_unlock(&linear_map_hash_lock);
|
|
|
|
if (hidx & _PTEIDX_SECONDARY)
|
|
|
|
hash = ~hash;
|
|
|
|
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
|
|
|
|
slot += hidx & _PTEIDX_GROUP_IX;
|
2016-07-05 12:03:58 +07:00
|
|
|
mmu_hash_ops.hpte_invalidate(slot, vpn, mmu_linear_psize,
|
|
|
|
mmu_linear_psize,
|
|
|
|
mmu_kernel_ssize, 0);
|
2007-04-12 12:30:23 +07:00
|
|
|
}
|
|
|
|
|
2014-12-13 07:55:52 +07:00
|
|
|
void __kernel_map_pages(struct page *page, int numpages, int enable)
|
2007-04-12 12:30:23 +07:00
|
|
|
{
|
|
|
|
unsigned long flags, vaddr, lmi;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
for (i = 0; i < numpages; i++, page++) {
|
|
|
|
vaddr = (unsigned long)page_address(page);
|
|
|
|
lmi = __pa(vaddr) >> PAGE_SHIFT;
|
|
|
|
if (lmi >= linear_map_hash_count)
|
|
|
|
continue;
|
|
|
|
if (enable)
|
|
|
|
kernel_map_linear_page(vaddr, lmi);
|
|
|
|
else
|
|
|
|
kernel_unmap_linear_page(vaddr, lmi);
|
|
|
|
}
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_DEBUG_PAGEALLOC */
|
2010-07-07 05:39:02 +07:00
|
|
|
|
2016-04-29 20:25:57 +07:00
|
|
|
void hash__setup_initial_memory_limit(phys_addr_t first_memblock_base,
|
2010-07-07 05:39:02 +07:00
|
|
|
phys_addr_t first_memblock_size)
|
|
|
|
{
|
|
|
|
/* We don't currently support the first MEMBLOCK not mapping 0
|
|
|
|
* physical on those processors
|
|
|
|
*/
|
|
|
|
BUG_ON(first_memblock_base != 0);
|
|
|
|
|
2017-12-22 18:17:08 +07:00
|
|
|
/*
|
|
|
|
* On virtualized systems the first entry is our RMA region aka VRMA,
|
|
|
|
* non-virtualized 64-bit hash MMU systems don't have a limitation
|
|
|
|
* on real mode access.
|
|
|
|
*
|
2017-12-22 18:17:12 +07:00
|
|
|
* For guests on platforms before POWER9, we clamp the it limit to 1G
|
|
|
|
* to avoid some funky things such as RTAS bugs etc...
|
2010-07-07 05:39:02 +07:00
|
|
|
*/
|
2017-12-22 18:17:08 +07:00
|
|
|
if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
|
2017-12-22 18:17:12 +07:00
|
|
|
ppc64_rma_size = first_memblock_size;
|
|
|
|
if (!early_cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
ppc64_rma_size = min_t(u64, ppc64_rma_size, 0x40000000);
|
2010-07-07 05:39:02 +07:00
|
|
|
|
2017-12-22 18:17:08 +07:00
|
|
|
/* Finally limit subsequent allocations */
|
|
|
|
memblock_set_current_limit(ppc64_rma_size);
|
|
|
|
} else {
|
|
|
|
ppc64_rma_size = ULONG_MAX;
|
|
|
|
}
|
2010-07-07 05:39:02 +07:00
|
|
|
}
|
2016-12-09 07:07:36 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
|
|
|
|
static int hpt_order_get(void *data, u64 *val)
|
|
|
|
{
|
|
|
|
*val = ppc64_pft_size;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hpt_order_set(void *data, u64 val)
|
|
|
|
{
|
|
|
|
if (!mmu_hash_ops.resize_hpt)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
return mmu_hash_ops.resize_hpt(val);
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_SIMPLE_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, "%llu\n");
|
|
|
|
|
|
|
|
static int __init hash64_debugfs(void)
|
|
|
|
{
|
|
|
|
if (!debugfs_create_file("hpt_order", 0600, powerpc_debugfs_root,
|
|
|
|
NULL, &fops_hpt_order)) {
|
|
|
|
pr_err("lpar: unable to create hpt_order debugsfs file\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
machine_device_initcall(pseries, hash64_debugfs);
|
|
|
|
#endif /* CONFIG_DEBUG_FS */
|