- 16 Aug, 2017 1 commit
-
-
Aneesh Kumar K.V authored
With commit aa888a74 ("hugetlb: support larger than MAX_ORDER") we added support for allocating gigantic hugepages via kernel command line. Switch ppc64 arch specific code to use that. W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC_ACCESSIBLE. We use the kernel command line to do reservation of hugetlb pages on powernv platforms. On pseries hash mmu mode the supported gigantic huge page size is 16GB and that can only be allocated with hypervisor assist. For pseries the command line option doesn't do the allocation. Instead pseries does gigantic hugepage allocation based on hypervisor hint that is specified via "ibm,expected#pages" property of the memory node. Cc: Scott Wood <oss@buserror.net> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
- 15 Aug, 2017 20 commits
-
-
Aneesh Kumar K.V authored
When running in guest mode ppc64 supports a different mechanism for hugetlb allocation/reservation. The LPAR management application called HMC can be used to reserve a set of hugepages and we pass the details of reserved pages via device tree to the guest. (more details in htab_dt_scan_hugepage_blocks()) . We do the memblock_reserve of the range and later in the boot sequence, we add the reserved range to huge_boot_pages. But to enable 16G hugetlb on baremetal config (when we are not running as guest) we want to do memblock reservation during boot. Generic code already does this Signed-off-by:
-
Christophe Leroy authored
gup_hugepte() checks if pages are present and readable, and when 'write' is set, also checks if the pages are writable. Initially this was done by checking if _PAGE_PRESENT and _PAGE_READ were set. In addition, _PAGE_WRITE was verified for write accesses. The problem is that we have to handle the three following cases: 1/ The target defines __PAGE_READ and __PAGE_WRITE 2/ The target defines __PAGE_RW 3/ The target defines __PAGE_RO In case 1/, this is obvious In case 2/, __PAGE_READ is defined as 0 and __PAGE_WRITE as __PAGE_RW so it works as well. But in case 3, __PAGE_RW is defined as 0, which means __PAGE_WRITE is 0 and then the test returns true (page writable) in all cases. A first correction was attempted in commit 6b8cb66a ("powerpc: Fix usage of _PAGE_RO in hugepage"), but that fix is wrong: instead of checking that the page is writable when write is requested, it checks that the page is NOT writable when write is NOT requested. This patch adds a new pte_read() helper to check whether a page is readable or not. This avoids handling all possible cases in gup_hugepte(). Then gup_hugepte() is modified to use pte_present(), pte_read() and pte_write() instead of the raw flags. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
-
Christophe Leroy authored
__set_fixmap() uses __fix_to_virt() then does the boundary checks by it self. Instead, we can use fix_to_virt() which does the verification at build time. For this, we need to use it inline so that GCC can see the real value of idx at buildtime. In the meantime, we remove the 'fixmaps' variable. This variable is set but has never been used from the beginning (commit 2c419bde ("[POWERPC] Port fixmap from x86 and use for kmap_atomic")) Signed-off-by:
-
Christophe Leroy authored
get_pteptr() and __mapin_ram_chunk() are only used locally, so define them static Signed-off-by:
-
Christophe Leroy authored
This patch implements STRICT_KERNEL_RWX on PPC32. As for CONFIG_DEBUG_PAGEALLOC, it deactivates BAT and LTLB mappings in order to allow page protection setup at the level of each page. As BAT/LTLB mappings are deactivated, there might be a performance impact. Signed-off-by:
-
Christophe Leroy authored
As seen below, allthough the init sections have been freed, the associated memory area is still marked as executable in the page tables. ~ dmesg [ 5.860093] Freeing unused kernel memory: 592K (c0570000 - c0604000) ~ cat /sys/kernel/debug/kernel_page_tables ---[ Start of kernel VM ]--- 0xc0000000-0xc0497fff 4704K rw X present dirty accessed shared 0xc0498000-0xc056ffff 864K rw present dirty accessed shared 0xc0570000-0xc059ffff 192K rw X present dirty accessed shared 0xc05a0000-0xc7ffffff 125312K rw present dirty accessed shared ---[ vmalloc() Area ]--- This patch fixes that. The implementation is done by reusing the change_page_attr() function implemented for CONFIG_DEBUG_PAGEALLOC Signed-off-by:
-
Christophe Leroy authored
__change_page_attr() uses flush_tlb_page(). flush_tlb_page() uses tlbie instruction, which also invalidates pinned TLBs, which is not what we expect. This patch modifies the implementation to use flush_tlb_kernel_range() instead. This will make use of tlbia which will preserve pinned TLBs. Signed-off-by:
-
Christophe Leroy authored
This reduces the DTLB miss handler hot path (user address path) by one instruction by preserving r10. Signed-off-by:
-
Christophe Leroy authored
setup_initial_memory_limit() is only called during init. mmu_patch_cmp_limit() is only called from 8xx_mmu.c Signed-off-by:
-
Christophe Leroy authored
Pinning TLBs bypasses STRICT_KERNEL_RWX or DEBUG_PAGEALLOC protections so it should only be allowed when those are not selected Signed-off-by:
-
Christophe Leroy authored
As stated in a comment in head_8xx.S, today we "Always pin the first 8 MB ITLB to prevent ITLB misses while mucking around with SRR0/SRR1 in asm". This issue has just been cleared by the preceding patch, therefore we can make this pinning optional (on by default) and independent of DATA pinning. This patch also makes pinning of IMMR independent of pinning of DATA. Signed-off-by:
-
Christophe Leroy authored
By default, the 8xx pins an ITLB on the first 8M of memory in order to avoid any ITLB miss on kernel code. However, with some debug functions like DEBUG_PAGEALLOC and DEBUG_RODATA, pinning TLBs is contradictory. In order to avoid any ITLB miss in a critical section without pinning TLBs, we have to ensure that there is no page boundary crossed between the setup of a new value in SRR0/SRR1 and the associated RFI. The functions modifying srr0/srr1 are all located in setup_32.S. They are spread over almost 4kbytes. The patch forces a 12 bits (4kbytes) alignment for those functions. This garanties that the functions remain in a single 4k page. Signed-off-by:
-
Christophe Leroy authored
The macro to check if an address is a kernel address or not is not used anymore in DTLBmiss handler. It is used in ITLB miss handler and in DTLB error handler. DTLB error handler is not a hot path, it doesn't need such optimisation. In order to simplify a following patch which will rework ITLB miss handler, we remove the macros and reintroduce them inside the handler. Signed-off-by:
-
Christophe Leroy authored
On the 8xx, the RAM mapped with LTLBs must be seen as block mapped, just like areas mapped with BATs on standard PPC32. Signed-off-by:
-
Julia Lawall authored
Normally the values in the resource field and the argument to ARRAY_SIZE in the num_resources are the same. In this case, the value in the reousrce field is the same as the one in the previous platform_device structure, and appears to be a copy-paste error. Replace the value in the resource field with the argument to the local call to ARRAY_SIZE. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Andreas Schwab authored
This fixes another invalid use of register expressions. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
-
Michael Ellerman authored
In iommu_range_alloc() we generate a mask by right shifting ~0, however if the specified alignment is 0 then we right shift by 64, which is undefined. UBSAN tells us so: UBSAN: Undefined behaviour in ../arch/powerpc/kernel/iommu.c:193:35 shift exponent 64 is too large for 64-bit type 'long unsigned int' We can avoid it by instead generating the mask with: align_mask = (1ull << align_order) - 1; That will also generate an undefined shift if align_order is 64 or greater, but that shouldn't be a problem for a while. Signed-off-by: -
Anju T authored
In a multi node system with discontiguous node ids, nest event values are not showing up properly. eg. lscpu output: NUMA node0 CPU(s): 0-15 NUMA node8 CPU(s): 16-31 Nest event values on such systems can be counted on CPUs <= 15: $./perf stat -e 'nest_powerbus0_imc/PM_PB_CYC/' -C 0-14 -I 1000 sleep 1000 # time counts unit events 1.000294577 30,17,24,42,880 nest_powerbus0_imc/PM_PB_CYC/ But not on CPUs >= 16: $./perf stat -e 'nest_powerbus0_imc/PM_PB_CYC/' -C 16-28 -I 1000 sleep 1000 # time counts unit events 1.000049902 <not supported> nest_powerbus0_imc/PM_PB_CYC/ This is because, when fetching the reference count, the node id (which may be sparse) is used as the array index, not the node number (which is 0 based and contiguous). Fix it by using the node number as the array index. $./perf stat -e 'nest_powerbus0_imc/PM_PB_CYC/' -C 16-28 -I 1000 sleep 1000 # time counts unit events 1.000241961 26,12,35,28,704 nest_powerbus0_imc/PM_PB_CYC/ Signed-off-by:Anju T Sudhakar <anju@linux.vnet.ibm.com> [mpe: Change log tweaks for clarity and brevity] Signed-off-by:
-
Michael Ellerman authored
In some obscure Book3E configs (randconfig) we can end up missing a definition for PGALLOC_GFP in pgtable_64.c. Fix it by moving the definition to asm/pgalloc.h. Fixes: de3b8761 ("powerpc/mm/book(e)(3s)/64: Add page table accounting") Signed-off-by:
-
Naveen N. Rao authored
Exclude core xmon files from ftrace (along with an xmon xive helper outside of xmon/) to minimize impact of ftrace while within xmon. Before: /sys/kernel/debug/tracing# grep -ci xmon available_filter_functions 26 After: /sys/kernel/debug/tracing# grep -ci xmon available_filter_functions 0 Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> [mpe: Use $(subst ..) on KBUILD_CFLAGS rather than CFLAGS_REMOVE_xxx] Signed-off-by:
-
- 14 Aug, 2017 5 commits
-
-
Breno Leitao authored
If tracing is enabled and you get into xmon, the tracing buffer continues to be updated, causing possible loss of data and unnecessary tracing information coming from xmon functions. This patch simple disables tracing when entering xmon, and re-enables it if the kernel is resumed (with 'x'). Signed-off-by:
Breno Leitao <leitao@debian.org> Acked-by:
-
Breno Leitao authored
Current xmon 'dt' command dumps the tracing buffer for all the CPUs, which makes it very hard to read due to the fact that most of powerpc machines currently have many CPUs. Other than that, the CPU lines are interleaved in the ftrace log. This new option just dumps the ftrace buffer for the current CPU. Signed-off-by:
-
Bhumika Goyal authored
Make wf_control_ops const as they are only stored in the ops field of a wf_control structure, which is const. Make wf_pid_param const as they are only used during a copy operation. Done using Coccinelle. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Dan Carpenter authored
This function is not called with the nest_init_lock held, and it also unlocks the nest_init_lock immediately below, so it's fairly clear that this is a typo and should be locking the lock. Fixes: 885dcd70 ("powerpc/perf: Add nest IMC PMU support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Christophe Leroy authored
Commit 968159c0 ("powerpc/8xx: Getting rid of remaining use of CONFIG_8xx") removed all but 2 references to 8xx in Kconfigs. This patch removes the two remaining ones. Fixes: 968159c0 ("powerpc/8xx: Getting rid of remaining use of CONFIG_8xx") Signed-off-by:
-
- 10 Aug, 2017 14 commits
-
-
Michael Ellerman authored
Both xive_core_init() and xive_native_init() are called from and call __init routines, so they should also be __init. Signed-off-by: -
Michael Ellerman authored
early_check_vec5() is called from and calls __init routines, so should also be __init. Signed-off-by: -
Christophe Leroy authored
head_8xx is dedicated to 8xx so no need to use macros that depends on the CPU Signed-off-by:
-
Christophe Leroy authored
Use symbolic names for DSISR bits in DSI Signed-off-by:
-
Christophe Leroy authored
For the 8xx, PVR values defined in arch/powerpc/include/asm/reg.h are nowhere used. Remove all defines and add PVR_8xx Use it in arch/powerpc/kernel/cputable.c Signed-off-by:
-
Christophe Leroy authored
Two config options exist to define powerpc MPC8xx: * CONFIG_PPC_8xx * CONFIG_8xx arch/powerpc/platforms/Kconfig.cputype has contained the following comment about CONFIG_8xx item for some years: "# this is temp to handle compat with arch=ppc" There is no more users of CONFIG_8xx, so remove it. Signed-off-by:
-
Christophe Leroy authored
Two config options exist to define powerpc MPC8xx: * CONFIG_PPC_8xx * CONFIG_8xx arch/powerpc/platforms/Kconfig.cputype has contained the following comment about CONFIG_8xx item for some years: "# this is temp to handle compat with arch=ppc" arch/powerpc is now the only place with remaining use of CONFIG_8xx: get rid of them. Signed-off-by:
-
Christophe Leroy authored
4xx, CPM2 and 8xx cannot be selected at the same time, so no need to test 8xx && !4xx && !CPM2. Testing 8xx is enough. Signed-off-by:
-
Christophe Leroy authored
The 8xx cannot access the TBL and TBU registers using mfspr/mtspr It must be accessed using mftb/mftbu Due to this, there is a number of places with #ifdef CONFIG_8xx This patch defines new macros MFTBL(x) and MFTBU(x) on the same model as MFTB(x) and tries to make use of them as much as possible. In arch/powerpc/include/asm/timex.h, we also remove the ifdef for the asm() operands as the compiler doesn't mind unused operands Signed-off-by:
-
Christophe Leroy authored
mpc8xx_pic.c is dedicated to the 8xx, so move it to platform/8xx Signed-off-by:
-
Christophe Leroy authored
To remain consistent with what is done with CPM2, let's link CPM1 related parts to CONFIG_CPM1 instead of CONFIG_8xx When something depends on both CPM1 and CPM2 we associate it with CONFIG_CPM Signed-off-by:
-
Christophe Leroy authored
Since commit aa42c69c ("[POWERPC] Add support for FP emulation for the e300c2 core"), program_check_exception() can be called for math emulation. In that case, 'reason' is 0. On the 8xx, there is a Software Emulation interrupt which is called for all unimplemented and illegal instructions. This interrupt calls SoftwareEmulation() which does almost the same as program_check_exception() called with reason = 0. The Software Emulation interrupt sets all reason bits to 0, it is therefore possible to call program_check_exception() directly from the interrupt handler. Signed-off-by:
-
Christophe Leroy authored
In the same spirit as what was done for 4xx and 44x, move the 8xx machine check into platforms/8xx Signed-off-by:
-
Christophe Leroy authored
The entire 8xx directory is omitted if CONFIG_8xx is not enabled, so within the 8xx/Makefile CONFIG_8xx is always y. So convert obj-$(CONFIG_8xx) to the more obvious obj-y. Signed-off-by:
-
