2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* Low-level SLB routines
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2004 David Gibson <dwg@au.ibm.com>, IBM
|
|
|
|
|
*
|
|
|
|
|
* Based on earlier C version:
|
|
|
|
|
* Dave Engebretsen and Mike Corrigan {engebret|mikejc}@us.ibm.com
|
|
|
|
|
* Copyright (c) 2001 Dave Engebretsen
|
|
|
|
|
* Copyright (C) 2002 Anton Blanchard <anton@au.ibm.com>, IBM
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <asm/processor.h>
|
|
|
|
|
#include <asm/ppc_asm.h>
|
2005-09-10 02:57:26 +08:00
|
|
|
#include <asm/asm-offsets.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/cputable.h>
|
2005-11-07 08:06:55 +08:00
|
|
|
#include <asm/page.h>
|
|
|
|
|
#include <asm/mmu.h>
|
|
|
|
|
#include <asm/pgtable.h>
|
2006-09-25 16:19:00 +08:00
|
|
|
#include <asm/firmware.h>
|
2018-07-06 00:25:01 +08:00
|
|
|
#include <asm/feature-fixups.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-03-29 14:21:53 +08:00
|
|
|
/*
|
|
|
|
|
* This macro generates asm code to compute the VSID scramble
|
|
|
|
|
* function. Used in slb_allocate() and do_stab_bolted. The function
|
|
|
|
|
* computed is: (protovsid*VSID_MULTIPLIER) % VSID_MODULUS
|
|
|
|
|
*
|
|
|
|
|
* rt = register containing the proto-VSID and into which the
|
|
|
|
|
* VSID will be stored
|
|
|
|
|
* rx = scratch register (clobbered)
|
|
|
|
|
* rf = flags
|
|
|
|
|
*
|
|
|
|
|
* - rt and rx must be different registers
|
|
|
|
|
* - The answer will end up in the low VSID_BITS bits of rt. The higher
|
|
|
|
|
* bits may contain other garbage, so you may need to mask the
|
|
|
|
|
* result.
|
|
|
|
|
*/
|
|
|
|
|
#define ASM_VSID_SCRAMBLE(rt, rx, rf, size) \
|
|
|
|
|
lis rx,VSID_MULTIPLIER_##size@h; \
|
|
|
|
|
ori rx,rx,VSID_MULTIPLIER_##size@l; \
|
|
|
|
|
mulld rt,rt,rx; /* rt = rt * MULTIPLIER */ \
|
|
|
|
|
/* \
|
|
|
|
|
* powermac get slb fault before feature fixup, so make 65 bit part \
|
|
|
|
|
* the default part of feature fixup \
|
|
|
|
|
*/ \
|
|
|
|
|
BEGIN_MMU_FTR_SECTION \
|
|
|
|
|
srdi rx,rt,VSID_BITS_65_##size; \
|
|
|
|
|
clrldi rt,rt,(64-VSID_BITS_65_##size); \
|
|
|
|
|
add rt,rt,rx; \
|
|
|
|
|
addi rx,rt,1; \
|
|
|
|
|
srdi rx,rx,VSID_BITS_65_##size; \
|
|
|
|
|
add rt,rt,rx; \
|
|
|
|
|
rldimi rf,rt,SLB_VSID_SHIFT_##size,(64 - (SLB_VSID_SHIFT_##size + VSID_BITS_65_##size)); \
|
|
|
|
|
MMU_FTR_SECTION_ELSE \
|
|
|
|
|
srdi rx,rt,VSID_BITS_##size; \
|
|
|
|
|
clrldi rt,rt,(64-VSID_BITS_##size); \
|
|
|
|
|
add rt,rt,rx; /* add high and low bits */ \
|
|
|
|
|
addi rx,rt,1; \
|
|
|
|
|
srdi rx,rx,VSID_BITS_##size; /* extract 2^VSID_BITS bit */ \
|
|
|
|
|
add rt,rt,rx; \
|
|
|
|
|
rldimi rf,rt,SLB_VSID_SHIFT_##size,(64 - (SLB_VSID_SHIFT_##size + VSID_BITS_##size)); \
|
|
|
|
|
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_68_BIT_VA)
|
|
|
|
|
|
|
|
|
|
|
2017-06-19 19:57:33 +08:00
|
|
|
/* void slb_allocate(unsigned long ea);
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
|
* Create an SLB entry for the given EA (user or kernel).
|
|
|
|
|
* r3 = faulting address, r13 = PACA
|
|
|
|
|
* r9, r10, r11 are clobbered by this function
|
2017-05-21 21:15:42 +08:00
|
|
|
* r3 is preserved.
|
2005-04-17 06:20:36 +08:00
|
|
|
* No other registers are examined or changed.
|
|
|
|
|
*/
|
2017-06-19 19:57:33 +08:00
|
|
|
_GLOBAL(slb_allocate)
|
2013-03-13 11:34:54 +08:00
|
|
|
/*
|
2018-03-26 18:04:48 +08:00
|
|
|
* Check if the address falls within the range of the first context, or
|
|
|
|
|
* if we may need to handle multi context. For the first context we
|
|
|
|
|
* allocate the slb entry via the fast path below. For large address we
|
|
|
|
|
* branch out to C-code and see if additional contexts have been
|
|
|
|
|
* allocated.
|
|
|
|
|
* The test here is:
|
|
|
|
|
* (ea & ~REGION_MASK) >= (1ull << MAX_EA_BITS_PER_CONTEXT)
|
2013-03-13 11:34:54 +08:00
|
|
|
*/
|
2018-03-26 18:04:48 +08:00
|
|
|
rldicr. r9,r3,4,(63 - MAX_EA_BITS_PER_CONTEXT - 4)
|
2013-03-13 11:34:54 +08:00
|
|
|
bne- 8f
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
srdi r9,r3,60 /* get region */
|
2013-03-13 11:34:54 +08:00
|
|
|
srdi r10,r3,SID_SHIFT /* get esid */
|
2005-12-06 00:24:33 +08:00
|
|
|
cmpldi cr7,r9,0xc /* cmp PAGE_OFFSET for later use */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-12-06 00:24:33 +08:00
|
|
|
/* r3 = address, r10 = esid, cr7 = <> PAGE_OFFSET */
|
2005-04-17 06:20:36 +08:00
|
|
|
blt cr7,0f /* user or kernel? */
|
|
|
|
|
|
[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 13:41:48 +08:00
|
|
|
/* Check if hitting the linear mapping or some other kernel space
|
2005-11-07 08:06:55 +08:00
|
|
|
*/
|
|
|
|
|
bne cr7,1f
|
|
|
|
|
|
|
|
|
|
/* Linear mapping encoding bits, the "li" instruction below will
|
|
|
|
|
* be patched by the kernel at boot
|
|
|
|
|
*/
|
2014-03-10 06:44:22 +08:00
|
|
|
.globl slb_miss_kernel_load_linear
|
|
|
|
|
slb_miss_kernel_load_linear:
|
2005-11-07 08:06:55 +08:00
|
|
|
li r11,0
|
2012-09-10 10:52:55 +08:00
|
|
|
/*
|
2017-03-29 20:10:22 +08:00
|
|
|
* context = (ea >> 60) - (0xc - 1)
|
2013-03-13 11:34:54 +08:00
|
|
|
* r9 = region id.
|
2012-09-10 10:52:55 +08:00
|
|
|
*/
|
2017-03-29 20:10:22 +08:00
|
|
|
subi r9,r9,KERNEL_REGION_CONTEXT_OFFSET
|
2013-03-13 11:34:54 +08:00
|
|
|
|
2007-10-11 18:37:10 +08:00
|
|
|
BEGIN_FTR_SECTION
|
2017-02-13 12:26:40 +08:00
|
|
|
b .Lslb_finish_load
|
2011-04-07 03:48:50 +08:00
|
|
|
END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
|
2017-02-13 12:26:40 +08:00
|
|
|
b .Lslb_finish_load_1T
|
2005-11-07 08:06:55 +08: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 13:41:48 +08:00
|
|
|
1:
|
|
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
|
cmpldi cr0,r9,0xf
|
|
|
|
|
bne 1f
|
2017-03-29 20:10:22 +08:00
|
|
|
/* Check virtual memmap region. To be patched at kernel boot */
|
2014-03-10 06:44:22 +08:00
|
|
|
.globl slb_miss_kernel_load_vmemmap
|
|
|
|
|
slb_miss_kernel_load_vmemmap:
|
[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 13:41:48 +08:00
|
|
|
li r11,0
|
|
|
|
|
b 6f
|
|
|
|
|
1:
|
|
|
|
|
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
|
|
|
|
|
|
powerpc/mm/hash64: Make vmalloc 56T on hash
On 64-bit book3s, with the hash MMU, we currently define the kernel
virtual space (vmalloc, ioremap etc.), to be 16T in size. This is a
leftover from pre v3.7 when our user VM was also 16T.
Of that 16T we split it 50/50, with half used for PCI IO and ioremap
and the other 8T for vmalloc.
We never bothered to make it any bigger because 8T of vmalloc ought to
be enough for anybody. But it turns out that's not true, the per cpu
allocator wants large amounts of vmalloc space, not to make large
allocations, but to allow a large stride between allocations, because
we use pcpu_embed_first_chunk().
With a bit of juggling we can increase the entire kernel virtual space
to 64T. The only real complication is the check of the address in the
SLB miss handler, see the comment in the code.
Although we could continue to split virtual space 50/50 as we do now,
no one seems to be running out of PCI IO or ioremap space. So instead
keep that as 8T, and use the remaining 56T for vmalloc.
In future we should be able to increase the kernel virtual space to
512T, the code already supports that, it just needs testing on older
hardware.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
2017-08-01 18:29:24 +08:00
|
|
|
/*
|
|
|
|
|
* r10 contains the ESID, which is the original faulting EA shifted
|
|
|
|
|
* right by 28 bits. We need to compare that with (H_VMALLOC_END >> 28)
|
|
|
|
|
* which is 0xd00038000. That can't be used as an immediate, even if we
|
|
|
|
|
* ignored the 0xd, so we have to load it into a register, and we only
|
|
|
|
|
* have one register free. So we must load all of (H_VMALLOC_END >> 28)
|
|
|
|
|
* into a register and compare ESID against that.
|
|
|
|
|
*/
|
|
|
|
|
lis r11,(H_VMALLOC_END >> 32)@h // r11 = 0xffffffffd0000000
|
|
|
|
|
ori r11,r11,(H_VMALLOC_END >> 32)@l // r11 = 0xffffffffd0003800
|
|
|
|
|
// Rotate left 4, then mask with 0xffffffff0
|
|
|
|
|
rldic r11,r11,4,28 // r11 = 0xd00038000
|
|
|
|
|
cmpld r10,r11 // if r10 >= r11
|
|
|
|
|
bge 5f // goto io_mapping
|
|
|
|
|
|
2017-08-01 18:29:23 +08:00
|
|
|
/*
|
|
|
|
|
* vmalloc mapping gets the encoding from the PACA as the mapping
|
|
|
|
|
* can be demoted from 64K -> 4K dynamically on some machines.
|
|
|
|
|
*/
|
2006-06-15 08:45:18 +08:00
|
|
|
lhz r11,PACAVMALLOCSLLP(r13)
|
2007-10-11 18:37:10 +08:00
|
|
|
b 6f
|
2006-06-15 08:45:18 +08:00
|
|
|
5:
|
2009-10-13 04:43:47 +08:00
|
|
|
/* IO mapping */
|
2014-03-10 06:44:22 +08:00
|
|
|
.globl slb_miss_kernel_load_io
|
|
|
|
|
slb_miss_kernel_load_io:
|
2005-11-07 08:06:55 +08:00
|
|
|
li r11,0
|
2007-10-11 18:37:10 +08:00
|
|
|
6:
|
2012-09-10 10:52:55 +08:00
|
|
|
/*
|
2017-03-29 20:10:22 +08:00
|
|
|
* context = (ea >> 60) - (0xc - 1)
|
2013-03-13 11:34:54 +08:00
|
|
|
* r9 = region id.
|
2012-09-10 10:52:55 +08:00
|
|
|
*/
|
2017-03-29 20:10:22 +08:00
|
|
|
subi r9,r9,KERNEL_REGION_CONTEXT_OFFSET
|
2013-03-13 11:34:54 +08:00
|
|
|
|
2007-10-11 18:37:10 +08:00
|
|
|
BEGIN_FTR_SECTION
|
2017-02-13 12:26:40 +08:00
|
|
|
b .Lslb_finish_load
|
2011-04-07 03:48:50 +08:00
|
|
|
END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
|
2017-02-13 12:26:40 +08:00
|
|
|
b .Lslb_finish_load_1T
|
2005-11-07 08:06:55 +08:00
|
|
|
|
2016-09-02 19:47:59 +08:00
|
|
|
0: /*
|
|
|
|
|
* For userspace addresses, make sure this is region 0.
|
|
|
|
|
*/
|
|
|
|
|
cmpdi r9, 0
|
2017-03-22 11:36:59 +08:00
|
|
|
bne- 8f
|
|
|
|
|
/*
|
|
|
|
|
* user space make sure we are within the allowed limit
|
|
|
|
|
*/
|
2017-11-10 01:27:40 +08:00
|
|
|
ld r11,PACA_SLB_ADDR_LIMIT(r13)
|
2017-03-22 11:36:59 +08:00
|
|
|
cmpld r3,r11
|
|
|
|
|
bge- 8f
|
2016-09-02 19:47:59 +08:00
|
|
|
|
2007-05-08 14:27:27 +08:00
|
|
|
/* when using slices, we extract the psize off the slice bitmaps
|
|
|
|
|
* and then we need to get the sllp encoding off the mmu_psize_defs
|
|
|
|
|
* array.
|
|
|
|
|
*
|
|
|
|
|
* XXX This is a bit inefficient especially for the normal case,
|
|
|
|
|
* so we should try to implement a fast path for the standard page
|
|
|
|
|
* size using the old sllp value so we avoid the array. We cannot
|
|
|
|
|
* really do dynamic patching unfortunately as processes might flip
|
|
|
|
|
* between 4k and 64k standard page size
|
|
|
|
|
*/
|
|
|
|
|
#ifdef CONFIG_PPC_MM_SLICES
|
2012-09-10 10:52:52 +08:00
|
|
|
/* r10 have esid */
|
[PATCH] ppc64: Fix bug in SLB miss handler for hugepages
This patch, however, should be applied on top of the 64k-page-size patch to
fix some problems with hugepage (some pre-existing, another introduced by
this patch).
The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of the
srd instruction's behaviour (mea culpa). The problem arises when a 64-bit
process maps some hugepages in the low 4GB of the address space (unusual).
In this case, as well as the 256M segment in question being marked for
hugepages, other segments at 32G intervals will be incorrectly marked for
hugepages.
In the process, this patch tweaks the semantics of the hugepage bitmaps to
be more sensible. Previously, an address below 4G was marked for hugepages
if the appropriate segment bit in the "low areas" bitmask was set *or* if
the low bit in the "high areas" bitmap was set (which would mark all
addresses below 1TB for hugepage). With this patch, any given address is
governed by a single bitmap. Addresses below 4GB are marked for hugepage
if and only if their bit is set in the "low areas" bitmap (256M
granularity). Addresses between 4GB and 1TB are marked for hugepage iff
the low bit in the "high areas" bitmap is set. Higher addresses are marked
for hugepage iff their bit in the "high areas" bitmap is set (1TB
granularity).
To avoid conflicts, this patch must be applied on top of BenH's pending
patch for 64k base page size [0]. As such, this patch also addresses a
hugepage problem introduced by that patch. That patch allows hugepages of
1MB in size on hardware which supports it, however, that won't work when
using 4k pages (4 level pagetable), because in that case hugepage PTEs are
stored at the PMD level, and each PMD entry maps 2MB. This patch simply
disallows hugepages in that case (we can do something cleverer to re-enable
them some other day).
Built, booted, and a handful of hugepage related tests passed on POWER5
LPAR (both ARCH=powerpc and ARCH=ppc64).
[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 16:57:52 +08:00
|
|
|
cmpldi r10,16
|
2012-09-10 10:52:52 +08:00
|
|
|
/* below SLICE_LOW_TOP */
|
[PATCH] ppc64: Fix bug in SLB miss handler for hugepages
This patch, however, should be applied on top of the 64k-page-size patch to
fix some problems with hugepage (some pre-existing, another introduced by
this patch).
The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of the
srd instruction's behaviour (mea culpa). The problem arises when a 64-bit
process maps some hugepages in the low 4GB of the address space (unusual).
In this case, as well as the 256M segment in question being marked for
hugepages, other segments at 32G intervals will be incorrectly marked for
hugepages.
In the process, this patch tweaks the semantics of the hugepage bitmaps to
be more sensible. Previously, an address below 4G was marked for hugepages
if the appropriate segment bit in the "low areas" bitmask was set *or* if
the low bit in the "high areas" bitmap was set (which would mark all
addresses below 1TB for hugepage). With this patch, any given address is
governed by a single bitmap. Addresses below 4GB are marked for hugepage
if and only if their bit is set in the "low areas" bitmap (256M
granularity). Addresses between 4GB and 1TB are marked for hugepage iff
the low bit in the "high areas" bitmap is set. Higher addresses are marked
for hugepage iff their bit in the "high areas" bitmap is set (1TB
granularity).
To avoid conflicts, this patch must be applied on top of BenH's pending
patch for 64k base page size [0]. As such, this patch also addresses a
hugepage problem introduced by that patch. That patch allows hugepages of
1MB in size on hardware which supports it, however, that won't work when
using 4k pages (4 level pagetable), because in that case hugepage PTEs are
stored at the PMD level, and each PMD entry maps 2MB. This patch simply
disallows hugepages in that case (we can do something cleverer to re-enable
them some other day).
Built, booted, and a handful of hugepage related tests passed on POWER5
LPAR (both ARCH=powerpc and ARCH=ppc64).
[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 16:57:52 +08:00
|
|
|
blt 5f
|
2012-09-10 10:52:52 +08:00
|
|
|
/*
|
|
|
|
|
* Handle hpsizes,
|
|
|
|
|
* r9 is get_paca()->context.high_slices_psize[index], r11 is mask_index
|
|
|
|
|
*/
|
|
|
|
|
srdi r11,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT + 1) /* index */
|
|
|
|
|
addi r9,r11,PACAHIGHSLICEPSIZE
|
|
|
|
|
lbzx r9,r13,r9 /* r9 is hpsizes[r11] */
|
|
|
|
|
/* r11 = (r10 >> (SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT)) & 0x1 */
|
|
|
|
|
rldicl r11,r10,(64 - (SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT)),63
|
|
|
|
|
b 6f
|
[PATCH] ppc64: Fix bug in SLB miss handler for hugepages
This patch, however, should be applied on top of the 64k-page-size patch to
fix some problems with hugepage (some pre-existing, another introduced by
this patch).
The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of the
srd instruction's behaviour (mea culpa). The problem arises when a 64-bit
process maps some hugepages in the low 4GB of the address space (unusual).
In this case, as well as the 256M segment in question being marked for
hugepages, other segments at 32G intervals will be incorrectly marked for
hugepages.
In the process, this patch tweaks the semantics of the hugepage bitmaps to
be more sensible. Previously, an address below 4G was marked for hugepages
if the appropriate segment bit in the "low areas" bitmask was set *or* if
the low bit in the "high areas" bitmap was set (which would mark all
addresses below 1TB for hugepage). With this patch, any given address is
governed by a single bitmap. Addresses below 4GB are marked for hugepage
if and only if their bit is set in the "low areas" bitmap (256M
granularity). Addresses between 4GB and 1TB are marked for hugepage iff
the low bit in the "high areas" bitmap is set. Higher addresses are marked
for hugepage iff their bit in the "high areas" bitmap is set (1TB
granularity).
To avoid conflicts, this patch must be applied on top of BenH's pending
patch for 64k base page size [0]. As such, this patch also addresses a
hugepage problem introduced by that patch. That patch allows hugepages of
1MB in size on hardware which supports it, however, that won't work when
using 4k pages (4 level pagetable), because in that case hugepage PTEs are
stored at the PMD level, and each PMD entry maps 2MB. This patch simply
disallows hugepages in that case (we can do something cleverer to re-enable
them some other day).
Built, booted, and a handful of hugepage related tests passed on POWER5
LPAR (both ARCH=powerpc and ARCH=ppc64).
[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 16:57:52 +08:00
|
|
|
|
2012-09-10 10:52:52 +08:00
|
|
|
5:
|
|
|
|
|
/*
|
|
|
|
|
* Handle lpsizes
|
2018-02-22 22:27:28 +08:00
|
|
|
* r9 is get_paca()->context.low_slices_psize[index], r11 is mask_index
|
2012-09-10 10:52:52 +08:00
|
|
|
*/
|
2018-02-22 22:27:28 +08:00
|
|
|
srdi r11,r10,1 /* index */
|
|
|
|
|
addi r9,r11,PACALOWSLICESPSIZE
|
|
|
|
|
lbzx r9,r13,r9 /* r9 is lpsizes[r11] */
|
|
|
|
|
rldicl r11,r10,0,63 /* r11 = r10 & 0x1 */
|
2012-09-10 10:52:52 +08:00
|
|
|
6:
|
|
|
|
|
sldi r11,r11,2 /* index * 4 */
|
|
|
|
|
/* Extract the psize and multiply to get an array offset */
|
2007-05-08 14:27:27 +08:00
|
|
|
srd r9,r9,r11
|
|
|
|
|
andi. r9,r9,0xf
|
|
|
|
|
mulli r9,r9,MMUPSIZEDEFSIZE
|
2005-08-11 14:55:21 +08:00
|
|
|
|
2007-05-08 14:27:27 +08:00
|
|
|
/* Now get to the array and obtain the sllp
|
|
|
|
|
*/
|
|
|
|
|
ld r11,PACATOC(r13)
|
|
|
|
|
ld r11,mmu_psize_defs@got(r11)
|
|
|
|
|
add r11,r11,r9
|
|
|
|
|
ld r11,MMUPSIZESLLP(r11)
|
|
|
|
|
ori r11,r11,SLB_VSID_USER
|
|
|
|
|
#else
|
|
|
|
|
/* paca context sllp already contains the SLB_VSID_USER bits */
|
2006-06-15 08:45:18 +08:00
|
|
|
lhz r11,PACACONTEXTSLLP(r13)
|
2007-05-08 14:27:27 +08:00
|
|
|
#endif /* CONFIG_PPC_MM_SLICES */
|
|
|
|
|
|
2005-11-07 08:06:55 +08:00
|
|
|
ld r9,PACACONTEXTID(r13)
|
2007-10-11 18:37:10 +08:00
|
|
|
BEGIN_FTR_SECTION
|
|
|
|
|
cmpldi r10,0x1000
|
2017-02-13 12:26:40 +08:00
|
|
|
bge .Lslb_finish_load_1T
|
2011-04-07 03:48:50 +08:00
|
|
|
END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
|
2017-02-13 12:26:40 +08:00
|
|
|
b .Lslb_finish_load
|
2005-11-07 08:06:55 +08:00
|
|
|
|
powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address
Currently, if userspace or the kernel accesses a completely bogus address,
for example with any of bits 46-59 set, we first take an SLB miss interrupt,
install a corresponding SLB entry with VSID 0, retry the instruction, then
take a DSI/ISI interrupt because there is no HPT entry mapping the address.
However, by the time of the second interrupt, the Come-From Address Register
(CFAR) has been overwritten by the rfid instruction at the end of the SLB
miss interrupt handler. Since bogus accesses can often be caused by a
function return after the stack has been overwritten, the CFAR value would
be very useful as it could indicate which function it was whose return had
led to the bogus address.
This patch adds code to create a full exception frame in the SLB miss handler
in the case of a bogus address, rather than inserting an SLB entry with a
zero VSID field. Then we call a new slb_miss_bad_addr() function in C code,
which delivers a signal for a user access or creates an oops for a kernel
access. In the latter case the oops message will show the CFAR value at the
time of the access.
In the case of the radix MMU, a segment miss interrupt indicates an access
outside the ranges mapped by the page tables. Previously this was handled
by the code for an unrecoverable SLB miss (one with MSR[RI] = 0), which is
not really correct. With this patch, we now handle these interrupts with
slb_miss_bad_addr(), which is much more consistent.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-09-02 19:49:21 +08:00
|
|
|
8: /* invalid EA - return an error indication */
|
|
|
|
|
crset 4*cr0+eq /* indicate failure */
|
|
|
|
|
blr
|
2005-11-07 08:06:55 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Finish loading of an SLB entry and return
|
|
|
|
|
*
|
2013-03-13 11:34:54 +08:00
|
|
|
* r3 = EA, r9 = context, r10 = ESID, r11 = flags, clobbers r9, cr7 = <> PAGE_OFFSET
|
2005-11-07 08:06:55 +08:00
|
|
|
*/
|
2017-02-13 12:26:40 +08:00
|
|
|
.Lslb_finish_load:
|
2013-03-13 11:34:55 +08:00
|
|
|
rldimi r10,r9,ESID_BITS,0
|
2017-03-29 14:21:53 +08:00
|
|
|
ASM_VSID_SCRAMBLE(r10,r9,r11,256M)
|
2005-11-07 08:06:55 +08:00
|
|
|
/* r3 = EA, r11 = VSID data */
|
|
|
|
|
/*
|
|
|
|
|
* Find a slot, round robin. Previously we tried to find a
|
|
|
|
|
* free slot first but that took too long. Unfortunately we
|
|
|
|
|
* dont have any LRU information to help us choose a slot.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-05-21 21:15:42 +08:00
|
|
|
mr r9,r3
|
|
|
|
|
|
|
|
|
|
/* slb_finish_load_1T continues here. r9=EA with non-ESID bits clear */
|
2007-10-11 18:37:10 +08:00
|
|
|
7: ld r10,PACASTABRR(r13)
|
2005-11-07 08:06:55 +08:00
|
|
|
addi r10,r10,1
|
2007-12-06 14:24:48 +08:00
|
|
|
/* This gets soft patched on boot. */
|
2014-03-10 06:44:22 +08:00
|
|
|
.globl slb_compare_rr_to_size
|
|
|
|
|
slb_compare_rr_to_size:
|
2007-12-06 14:24:48 +08:00
|
|
|
cmpldi r10,0
|
2005-11-07 08:06:55 +08:00
|
|
|
|
|
|
|
|
blt+ 4f
|
|
|
|
|
li r10,SLB_NUM_BOLTED
|
|
|
|
|
|
|
|
|
|
4:
|
|
|
|
|
std r10,PACASTABRR(r13)
|
|
|
|
|
|
|
|
|
|
3:
|
2017-05-21 21:15:42 +08:00
|
|
|
rldimi r9,r10,0,36 /* r9 = EA[0:35] | entry */
|
|
|
|
|
oris r10,r9,SLB_ESID_V@h /* r10 = r9 | SLB_ESID_V */
|
2005-11-07 08:06:55 +08:00
|
|
|
|
2017-05-21 21:15:42 +08:00
|
|
|
/* r9 = ESID data, r11 = VSID data */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* No need for an isync before or after this slbmte. The exception
|
|
|
|
|
* we enter with and the rfid we exit with are context synchronizing.
|
|
|
|
|
*/
|
|
|
|
|
slbmte r11,r10
|
|
|
|
|
|
2005-11-07 08:06:55 +08:00
|
|
|
/* we're done for kernel addresses */
|
|
|
|
|
crclr 4*cr0+eq /* set result to "success" */
|
|
|
|
|
bgelr cr7
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/* Update the slb cache */
|
2017-05-21 21:15:42 +08:00
|
|
|
lhz r9,PACASLBCACHEPTR(r13) /* offset = paca->slb_cache_ptr */
|
|
|
|
|
cmpldi r9,SLB_CACHE_ENTRIES
|
2005-04-17 06:20:36 +08:00
|
|
|
bge 1f
|
|
|
|
|
|
|
|
|
|
/* still room in the slb cache */
|
2017-05-21 21:15:42 +08:00
|
|
|
sldi r11,r9,2 /* r11 = offset * sizeof(u32) */
|
2012-09-10 10:52:54 +08:00
|
|
|
srdi r10,r10,28 /* get the 36 bits of the ESID */
|
|
|
|
|
add r11,r11,r13 /* r11 = (u32 *)paca + offset */
|
|
|
|
|
stw r10,PACASLBCACHE(r11) /* paca->slb_cache[offset] = esid */
|
2017-05-21 21:15:42 +08:00
|
|
|
addi r9,r9,1 /* offset++ */
|
2005-04-17 06:20:36 +08:00
|
|
|
b 2f
|
|
|
|
|
1: /* offset >= SLB_CACHE_ENTRIES */
|
2017-05-21 21:15:42 +08:00
|
|
|
li r9,SLB_CACHE_ENTRIES+1
|
2005-04-17 06:20:36 +08:00
|
|
|
2:
|
2017-05-21 21:15:42 +08:00
|
|
|
sth r9,PACASLBCACHEPTR(r13) /* paca->slb_cache_ptr = offset */
|
2005-11-07 08:06:55 +08:00
|
|
|
crclr 4*cr0+eq /* set result to "success" */
|
2005-04-17 06:20:36 +08:00
|
|
|
blr
|
|
|
|
|
|
2007-10-11 18:37:10 +08:00
|
|
|
/*
|
|
|
|
|
* Finish loading of a 1T SLB entry (for the kernel linear mapping) and return.
|
|
|
|
|
*
|
2013-03-13 11:34:54 +08:00
|
|
|
* r3 = EA, r9 = context, r10 = ESID(256MB), r11 = flags, clobbers r9
|
2007-10-11 18:37:10 +08:00
|
|
|
*/
|
2017-02-13 12:26:40 +08:00
|
|
|
.Lslb_finish_load_1T:
|
2013-03-13 11:34:54 +08:00
|
|
|
srdi r10,r10,(SID_SHIFT_1T - SID_SHIFT) /* get 1T ESID */
|
2013-03-13 11:34:55 +08:00
|
|
|
rldimi r10,r9,ESID_BITS_1T,0
|
2017-03-29 14:21:53 +08:00
|
|
|
ASM_VSID_SCRAMBLE(r10,r9,r11,1T)
|
|
|
|
|
|
2007-10-11 18:37:10 +08:00
|
|
|
li r10,MMU_SEGSIZE_1T
|
|
|
|
|
rldimi r11,r10,SLB_VSID_SSIZE_SHIFT,0 /* insert segment size */
|
|
|
|
|
|
|
|
|
|
/* r3 = EA, r11 = VSID data */
|
2017-05-21 21:15:42 +08:00
|
|
|
clrrdi r9,r3,SID_SHIFT_1T /* clear out non-ESID bits */
|
2007-10-11 18:37:10 +08:00
|
|
|
b 7b
|
|
|
|
|
|
2017-02-13 12:30:19 +08:00
|
|
|
|
2017-06-19 19:57:33 +08:00
|
|
|
_ASM_NOKPROBE_SYMBOL(slb_allocate)
|
2017-02-13 12:30:19 +08:00
|
|
|
_ASM_NOKPROBE_SYMBOL(slb_miss_kernel_load_linear)
|
|
|
|
|
_ASM_NOKPROBE_SYMBOL(slb_miss_kernel_load_io)
|
|
|
|
|
_ASM_NOKPROBE_SYMBOL(slb_compare_rr_to_size)
|
|
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP
|
|
|
|
|
_ASM_NOKPROBE_SYMBOL(slb_miss_kernel_load_vmemmap)
|
|
|
|
|
#endif
|