- 10 Aug, 2017 2 commits
-
-
Nathan Fontenot authored
When DLPAR adding or removing memory we need to check the device offline status before trying to online/offline the memory. This is needed because calls to device_online() and device_offline() will return non-zero for memory that is already online and offline respectively. This update resolves two scenarios. First, for a kernel built with auto-online memory enabled (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y), memory will be onlined as part of calls to add_memory(). After adding the memory the pseries DLPAR code tries to online it and fails since the memory is already online. The DLPAR code then tries to remove the memory which produces the oops message below because the memory is not offline. The second scenario occurs when removing memory that is already offline, i.e. marking memory offline (via sysfs) and then trying to remove that memory. This doesn't work because offlining the already offline memory does not succeed and the DLPAR code then fails the DLPAR remove operation. The fix for both scenarios is to check the device.offline status before making the calls to device_online() or device_offline(). kernel BUG at mm/memory_hotplug.c:1936! ... NIP [c0000000002ca428] .remove_memory+0xb8/0xc0 LR [c0000000002ca3cc] .remove_memory+0x5c/0xc0 Call Trace: .remove_memory+0x5c/0xc0 (unreliable) .dlpar_add_lmb+0x384/0x400 .dlpar_memory+0x5dc/0xca0 .handle_dlpar_errorlog+0x74/0xe0 .pseries_hp_work_fn+0x2c/0x90 .process_one_work+0x17c/0x460 .worker_thread+0x88/0x500 .kthread+0x15c/0x1a0 .ret_from_kernel_thread+0x58/0xc0 Fixes: 943db62c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'") Signed-off-by:Nathan Fontenot <nfont@linux.vnet.ibm.com> [mpe: Use bool, add explicit rc=0 case, change log typos & formatting] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Andreas Schwab authored
binutils >= 2.26 now warns about misuse of register expressions in assembler operands that are actually literals, for example: arch/powerpc/kernel/entry_64.S:535: Warning: invalid register expression In practice these are almost all uses of r0 that should just be a literal 0. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> [mpe: Mention r0 is almost always the culprit, fold in purgatory change] Signed-off-by:
-
- 08 Aug, 2017 6 commits
-
-
Michael Ellerman authored
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:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
-
Michael Ellerman authored
There is a comment in slb_allocate() referring to the load of paca->vmalloc_sllp, but it's several lines prior in the assembly. We're about to change this code, and we want to add another comment, so move the comment immediately prior to the instruction it's talking about. Signed-off-by:
-
Michael Ellerman authored
Currently KERN_IO_START is defined as: #define KERN_IO_START (KERN_VIRT_START + (KERN_VIRT_SIZE >> 1)) Although it looks like a constant, both the components are actually variables, to allow us to have a different value between Radix and Hash with a single kernel. However that still requires both Radix and Hash to place the kernel IO region at the same location relative to the start and end of the kernel virtual region (namely 1/2 way through it), and we'd like to change that. So split KERN_IO_START out into its own variable, and initialise it for Radix and Hash. In the medium term we should be able to reconsolidate this, by doing a more involved rearrangement of the location of the regions. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Signed-off-by:
-
Matt Brown authored
This adds powernv_get_random_darn() which utilises the darn instruction, introduced in ISA v3.0/POWER9. The darn instruction can potentially return an error, which is supported by the get_random_seed() API, in normal usage if we see an error we just return that to the caller. However when detecting whether darn is functional at boot we try up to 10 times, before deciding that darn doesn't work and failing the registration of get_random_seed(). That way an intermittent failure at boot doesn't deprive the system of randomness until the next reboot. Signed-off-by:
Matt Brown <matthew.brown.dev@gmail.com> [mpe: Move init into a function, tweak change log] Signed-off-by:
-
Christophe Leroy authored
Commit d300627c ("powerpc/6xx: Handle DABR match before calling do_page_fault") breaks non 6xx platforms. Failed to execute /init (error -14) Starting init: /bin/sh exists but couldn't execute it (error -14) Kernel panic - not syncing: No working init found. Try passing init= ... CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc3-s3k-dev-00143-g7aa62e972a56 #56 Call Trace: panic+0x108/0x250 (unreliable) rootfs_mount+0x0/0x58 ret_from_kernel_thread+0x5c/0x64 Rebooting in 180 seconds.. This is because in handle_page_fault(), the call to do_page_fault() has been mistakenly enclosed inside an #ifdef CONFIG_6xx Fixes: d300627c ("powerpc/6xx: Handle DABR match before calling do_page_fault") Brown-paper-bag-to-be-worn-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Frederic Barrat authored
P9 has support for PCI peer-to-peer, enabling a device to write in the MMIO space of another device directly, without interrupting the CPU. This patch adds support for it on powernv, by adding a new API to be called by drivers. The pnv_pci_set_p2p(...) call configures an 'initiator', i.e the device which will issue the MMIO operation, and a 'target', i.e. the device on the receiving side. P9 really only supports MMIO stores for the time being but that's expected to change in the future, so the API allows to define both load and store operations. /* PCI p2p descriptor */ #define OPAL_PCI_P2P_ENABLE 0x1 #define OPAL_PCI_P2P_LOAD 0x2 #define OPAL_PCI_P2P_STORE 0x4 int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target, u64 desc) It uses a new OPAL call, as the configuration magic is done on the PHBs by skiboot. Signed-off-by:Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by:
Russell Currey <ruscur@russell.cc> [mpe: Drop unrelated OPAL calls, s/uint64_t/u64/, minor formatting] Signed-off-by:
-
- 03 Aug, 2017 22 commits
-
-
Benjamin Herrenschmidt authored
We have a whole pile of unused code to maintain the ACOP register, allocate coprocessor PIDs and handle ACOP faults. This mechanism was used for the HFI adapter on POWER7 which is dead and gone and whose driver never went upstream. It was used on some A2 core based stuff that also never saw the light of day. Take out all that code. There is still some POWER8 coprocessor code that uses icswx but it's kernel only and thus doesn't use any of that infrastructure. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
When hitting below a VM_GROWSDOWN vma (typically growing the stack), we check whether it's a valid stack-growing instruction and we check the distance to GPR1. This is largely open coded with lots of comments, so move it out to a helper. While at it, make store_update_sp a boolean. Signed-off-by:
-
Benjamin Herrenschmidt authored
If the first iteration returns VM_FAULT_MAJOR but the second one doesn't, we fail to account the fault as a major fault. This fixes it and brings the code in line with x86. Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
Move out the code that sets FAULT_FLAG_WRITE so the block that check access permissions can be extracted. While at it also set FAULT_FLAG_INSTRUCTION which will be used for protection keys. Signed-off-by:
-
Benjamin Herrenschmidt authored
Mostly for the failure cases Signed-off-by:
-
Benjamin Herrenschmidt authored
Do the check before we re-enable interrupts and clean the code up a bit. Signed-off-by:
-
Benjamin Herrenschmidt authored
This has a page of comment explaining what's going on right in the middle of do_page_fault() which makes things a bit hard to follow. Move it to a helper instead. Also do the test earlier as there's no point waiting until after we found the VMA. Signed-off-by:
-
Benjamin Herrenschmidt authored
No need to break those lines, they aren't that long Signed-off-by:
-
Benjamin Herrenschmidt authored
It makes do_page_fault() more readable. No functional change. Signed-off-by:
-
Benjamin Herrenschmidt authored
First, handle the normal retry failure in do_page_fault itself, since it's a simple return statement. That allows us to remove the "continue" special return code from mm_fault_error(). Once that's done, we can have an implementation much closer to x86 where we only call mm_fault_error() if VM_FAULT_ERROR is set and directly return. Signed-off-by:
-
Benjamin Herrenschmidt authored
Instead of goto labels, instead call those functions and return. This gets us closer to x86 and allows us to shring do_page_fault() even more. The main difference with x86 is that those function return a value which we then return from do_page_fault(). That value is our return value from do_page_fault() which we use to generate kernel faults. Signed-off-by:
-
Benjamin Herrenschmidt authored
We currently test for is_exec and DSISR_PROTFAULT but that doesn't make sense as this is the wrong error bit to test for an execute permission failure. In fact, we had code that would return early if we had an exec fault in kernel mode so I think that was just dead code anyway. Finally the location of that test is awkward and prevents further simplifications. So instead move that test into a helper along with the existing early test for kernel exec faults and out of range accesses, and put it all in a "bad_kernel_fault()" helper. While at it test the correct error bits. Signed-off-by:
-
Benjamin Herrenschmidt authored
Now that we moved the exception state handling to a wrapper, we can just directly return rather than "goto bail" Signed-off-by:
-
Benjamin Herrenschmidt authored
unclutters the main path Signed-off-by:
-
Benjamin Herrenschmidt authored
A bad page fault is when the HW signals an error such as a bad copy/paste, an AMO error, or some other type of error that will not be fixed by updating the PTE. Use a helper page_fault_is_bad() to check for bad page faults thus removing the per-processor family open-coding in __do_page_fault() and trigger a SIGBUS rather than a SIGSEGV which is more appropriate. Signed-off-by:
-
Benjamin Herrenschmidt authored
There's no point looking for the VMA etc.. when we already know we are going to fail. This adds some code to set "code" for the si_code but that will be gone in subsequent patches. Signed-off-by:
-
Benjamin Herrenschmidt authored
Define a common page_fault_is_write() helper and use it Signed-off-by:
-
Benjamin Herrenschmidt authored
This uses the newly defined constants for this rather than open-coded numbers. There is a side effect on 64-bit which is to pass through some of the new P9 bits which we didn't before. Signed-off-by:
-
Benjamin Herrenschmidt authored
We test a number of bits from DSISR/SRR1 before deciding to call hash_page(). If any of these is set, we go directly to do_page_fault() as the bit indicate a fault that needs to be handled there (no hashing needed). This updates the current open-coded masks to use the new DSISR definitions. This *does* change the masks actually used in two ways: - We used to test various bits that were defined as "always 0" in the architecture and could be repurposed for something else. From now on, we just ignore such bits. - We were missing some new bits defined on P9 Signed-off-by:
-
Benjamin Herrenschmidt authored
This updates the definitions for the various DSISR bits to match both some historical stuff and to match new bits on POWER9. In addition, we define some masks corresponding to the "bad" faults on Book3S, and some masks corresponding to the bits that match between DSISR and SRR1 for a DSI and an ISI. This comes with a small code update to change the definition of DSISR_PGDIRFAULT which becomes DSISR_PRTABLE_FAULT to match architecture 3.0B Signed-off-by:
-
Benjamin Herrenschmidt authored
On legacy 6xx 32-bit procesors, we checked for the DABR match bit in DSISR from do_page_fault(), in the middle of a pile of ifdef's because all other CPU types do it in assembly prior to calling do_page_fault. Fix that. Signed-off-by:
-
- 02 Aug, 2017 5 commits
-
-
Benjamin Herrenschmidt authored
By filtering the relevant SRR1 bits in the assembly rather than in do_page_fault() itself, we avoid a conditional branch (since we already come from different path for data and instruction faults). This will allow more simplifications later Signed-off-by:
-
Benjamin Herrenschmidt authored
This will allow simplifying the returns from do_page_fault Signed-off-by:
-
Benjamin Herrenschmidt authored
We do that because it's used by THP pmd collapsing, so use instead a dedicated flush function. Signed-off-by:
-
Benjamin Herrenschmidt authored
At the moment we have to rather sub-optimal flushing behaviours: - flush_tlb_mm() will flush the PWC which is unnecessary (for example when doing a fork) - A large unmap will call flush_tlb_pwc() multiple times causing us to perform that fairly expensive operation repeatedly. This happens often in batches of 3 on every new process. So we change flush_tlb_mm() to only flush the TLB, and we use the existing "need_flush_all" flag in struct mmu_gather to indicate that the PWC needs flushing. Unfortunately, flush_tlb_range() still needs to do a full flush for now as it's used by the THP collapsing. We will fix that later. Signed-off-by:
-
Benjamin Herrenschmidt authored
The PWC flush only needs a single set call, just like the full (RIC=2) flush. This will allow us to get rid of the dedicated _tlbiel_pwc() Signed-off-by:
-
- 01 Aug, 2017 3 commits
-
-
Victor Aoqui authored
Replace the __this_cpu_read() with raw_cpu_read() in iommu_range_alloc(). Otherwise we get a warning about using __this_cpu_read() in preemptible code: BUG: using __this_cpu_read() in preemptible caller is iommu_range_alloc+0xa8/0x3d0 Preemption doesn't need to be disabled since according to the comment any CPU can safely use any IOMMU pool. Signed-off-by:
Victor Aoqui <victora@linux.vnet.ibm.com> Signed-off-by:
-
Gautham R. Shenoy authored
Currently we use the stop-api provided by the firmware to program the SLW engine to restore the values of hypervisor resources that get lost on deeper idle states (such as winkle). Since the deep states were only used for CPU-Hotplug on POWER8 systems, we would program the LPCR to have the PECE1 bit since Hotplugged CPUs shouldn't be spuriously woken up by decrementer. On POWER9, some of the deep platform idle states such as stop4 can be used in cpuidle as well. In this case, we want the CPU in stop4 to be woken up by the decrementer when some timer on the CPU expires. In this patch, we program the stop-api for LPCR with PECE1 bit cleared only when we are offlining the CPU and set it back once the CPU is online. Signed-off-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Gautham R. Shenoy authored
The stop4 idle state on POWER9 is a deep idle state which loses hypervisor resources, but whose latency is low enough that it can be exposed via cpuidle. Until now, the deep idle states which lose hypervisor resources (eg: winkle) were only exposed via CPU-Hotplug. Hence currently on wakeup from such states, barring a few SPRs which need to be restored to their older value, rest of the SPRS are reinitialized to their values corresponding to that at boot time. When stop4 is used in the context of cpuidle, we want these additional SPRs to be restored to their older value, to ensure that the context on the CPU coming back from idle is same as it was before going idle. In this patch, we define a SPR save area in PACA (since we have used up the volatile register space in the stack) and on POWER9, we restore SPRN_PID, SPRN_LDBAR, SPRN_FSCR, SPRN_HFSCR, SPRN_MMCRA, SPRN_MMCR1, SPRN_MMCR2 to the values they had before entering stop. Signed-off-by:
-
- 31 Jul, 2017 2 commits
-
-
Rui Teng authored
The offset of hugepage block will not be 16G, if the expected page is more than one. Calculate the totol size instead of the hardcode value. Fixes: 4792adba ("powerpc: Don't use a 16G page if beyond mem= limits") Signed-off-by:
Rui Teng <rui.teng@linux.vnet.ibm.com> Tested-by:
Anshuman Khandual <khandual@linux.vnet.ibm.com> Signed-off-by:
-
Michael Ellerman authored
For debugging very early boot problems we have CONFIG_PPC_EARLY_DEBUG, which allows configuring the kernel such that it unconditionally writes to a particular type of console, regardless of whether that console exists or not. This is useful sometimes when the kernel crashes before it can even determine what platform it's on, and therefore what consoles exist. However if you boot a kernel built this way on a different platform, it will generally crash because it writes to a console that doesn't exist. A particularly nasty instance of this is if you enable the hypervisor console early debug, and then boot that kernel on bare metal. The result is that the kernel calls "the hypervisor" very early in boot, but the kernel *is* the hypervisor, so we jump to the system call handler and start executing all sorts of code that isn't ready to be run. This may lead to a machine check or check stop depending on how lucky you are. Luckily there is an easy way to avoid this particular case. We simply read the MSR before installing the hooks, and if we see MSR_HV is set then we are the hypervisor and we definitely should not use the hypervisor console. Signed-off-by:
-
