- 21 Feb, 2019 1 commit
-
-
Michael Ellerman authored
Merge hch's big DMA rework series. This is in a topic branch in case he wants to merge it to minimise conflicts.
-
- 19 Feb, 2019 1 commit
-
-
Michael Ellerman authored
There's a few important fixes in our fixes branch, in particular the pgd/pud_present() one, so merge it now.
-
- 18 Feb, 2019 32 commits
-
-
Christoph Hellwig authored
There is no need to provide anything but get_arch_dma_ops to <linux/dma-mapping.h>. More the remaining declarations to <asm/iommu.h> and drop all the includes. Signed-off-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Christoph Hellwig authored
There is no good reason for this helper, just opencode it. Signed-off-by:
-
Christoph Hellwig authored
Just fold the calculation into __phys_to_dma/__dma_to_phys as those are the only places that should know about it. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
-
Christoph Hellwig authored
Now that we've switched all the powerpc nommu and swiotlb methods to use the generic dma_direct_* calls we can remove these ops vectors entirely and rely on the common direct mapping bypass that avoids indirect function calls entirely. This also allows to remove a whole lot of boilerplate code related to setting up these operations. Signed-off-by:
-
Christoph Hellwig authored
Switch the streaming DMA mapping and ownership transfer methods to the functionally identical dma_direct_ versions. Factor the cache maintainance helpers into the form expected by the common code for that. Signed-off-by:
-
Christoph Hellwig authored
The generic code allows a few nice things such as node local allocations and dipping into the CMA area. The lookup of the right zone for a given dma mask works a little different, but the results should be the same. Signed-off-by:
-
Christoph Hellwig authored
The only user left is powerpc, but even there the generic dma-direct version works just as well, given that we guarantee that the swiotlb buffer must always be addressable. Signed-off-by:
-
Christoph Hellwig authored
This function is largely identical to the generic version used everywhere else. Replace it with the generic version. Signed-off-by:
-
Christoph Hellwig authored
This function is identical to the generic dma_direct_get_required_mask, except that the generic version also takes the bus_dma_mask account, which could lead to incorrect results in the powerpc version. Signed-off-by:
-
Christoph Hellwig authored
The coherent cache version of this function already is functionally identicall to the default version, and by defining the arch_dma_coherent_to_pfn hook the same is ture for the noncoherent version as well. Signed-off-by:
-
Christoph Hellwig authored
Use the standard portable helper instead of the powerpc specific one, which is about to go away. Signed-off-by:
-
Christoph Hellwig authored
Instead of letting the architecture supply all of dma_set_mask just give it an additional hook selected by Kconfig. Signed-off-by:
-
Christoph Hellwig authored
We need to compare the last byte in the dma range and not the one after it for the bus_dma_mask, just like we do for the regular dma_mask. Fix this cleanly by merging the two comparisms into one. Signed-off-by:
-
Christoph Hellwig authored
The max_direct_dma_addr duplicates the bus_dma_mask field in struct device. Use the generic field instead. Signed-off-by:
-
Christoph Hellwig authored
pci_dma_dev_setup_swiotlb is only used by the fsl_pci code, and closely related to it, so fsl_pci.c seems like a better place for it. Signed-off-by:
-
Christoph Hellwig authored
This function is only used by the Cell iommu code, which can keep track if it is using the iommu internally just as good. Signed-off-by:
-
Christoph Hellwig authored
All iommu capable platforms now always use the iommu code with the internal bypass, so there is not need for this magic anymore. Signed-off-by:
-
Christoph Hellwig authored
Unused now. Signed-off-by:
-
Christoph Hellwig authored
The ppc_md and pci_controller_ops methods are unused now and can be removed. The dma_nommu implementation is generic to the generic one except for using max_pfn instead of calling into the memblock API, and all other dma_map_ops instances implement a method of their own. Signed-off-by:
-
Christoph Hellwig authored
Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by:
-
Christoph Hellwig authored
These devices are not PCIe devices and do not have associated dma map ops, so this is just dead code. Signed-off-by:
-
Christoph Hellwig authored
This function is completely bogus - the fact that two PCIe devices come from the same vendor has absolutely nothing to say about the DMA capabilities and characteristics. Signed-off-by:
-
Christoph Hellwig authored
Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by:
-
Christoph Hellwig authored
If dart_init failed we didn't have a chance to setup dma or controller ops yet, so there is no point in resetting them. Signed-off-by:
-
Christoph Hellwig authored
This gets rid of a lot of clumsy code and finally allows us to mark dma_iommu_ops const. Includes fixes from Michael Ellerman. Signed-off-by:
-
Christoph Hellwig authored
Configure the dma settings at device setup time, and stop playing games with get_pci_dma_ops. This prepares for using the common dma_configure code later on. Includes fixes from Michael Ellerman. Signed-off-by:
-
Christoph Hellwig authored
Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by:
-
Christoph Hellwig authored
Call dma_get_required_mask_pSeriesLP directly instead of dma_iommu_ops to simply the code a bit. Signed-off-by:
-
Christoph Hellwig authored
Add a new iommu_bypass flag to struct dev_archdata so that the dma_iommu implementation can handle the direct mapping transparently instead of switiching ops around. Setting of this flag is controlled by new pci_controller_ops method. Signed-off-by:
-
Christoph Hellwig authored
vio_dma_mapping_ops currently does a lot of indirect calls through dma_iommu_ops, which not only make the code harder to follow but are also expensive in the post-spectre world. Unwind the indirect calls by calling the ppc_iommu_* or iommu_* APIs directly applicable, or just use the dma_iommu_* methods directly where we can. Signed-off-by:
-
Christoph Hellwig authored
If there is no ZONE_DMA32 we might need GFP_DMA to be able to allocate memory that satisfies a 32-bit DMA mask. Reported-by:
-
Christoph Hellwig authored
The pasemi driver never set a DMA mask, and given that the powerpc DMA mapping routines never check it this worked ok so far. But the generic dma-direct code which I plan to switch on for powerpc checks the DMA mask and fails unsupported mapping requests, so we need to make sure the proper 64-bit mask is set. Reported-by:
-
- 17 Feb, 2019 1 commit
-
-
Michael Ellerman authored
In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT rather than just checking that the value is non-zero, e.g.: static inline int pgd_present(pgd_t pgd) { - return !pgd_none(pgd); + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT)); } Unfortunately this is broken on big endian, as the result of the bitwise & is truncated to int, which is always zero because _PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and pud_present() are always false at compile time, and the compiler elides the subsequent code. Remarkably with that bug present we are still able to boot and run with few noticeable effects. However under some work loads we are able to trigger a warning in the ext4 code: WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0 CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1 ... NIP .ext4_set_page_dirty+0x70/0xb0 LR .set_page_dirty+0xa0/0x150 Call Trace: .set_page_dirty+0xa0/0x150 .unmap_page_range+0xbf0/0xe10 .unmap_vmas+0x84/0x130 .unmap_region+0xe8/0x190 .__do_munmap+0x2f0/0x510 .__vm_munmap+0x80/0x110 .__se_sys_munmap+0x14/0x30 system_call+0x5c/0x70 The fix is simple, we need to convert the result of the bitwise & to an int before returning it. Thanks to Erhard, Jan Kara and Aneesh for help with debugging. Fixes: da7ad366 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit") Cc: stable@vger.kernel.org # v4.20+ Reported-by:Erhard F. <erhard_f@mailbox.org> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
-
- 06 Feb, 2019 2 commits
-
-
Oliver O'Halloran authored
The IODA reset is used to flush out any OS controlled state from the PHB. This reset can fail if a PHB fatal error has occurred in early boot, probably due to a because of a bad device. We already do a fundemental reset of the device in some cases, so this patch just adds a test to force a full reset if firmware reports an error when performing the IODA reset. Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
-
Breno Leitao authored
'regno' is directly controlled by user space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the register number that would be read or written. This register number is called 'regno' which is part of the 'addr' syscall parameter. This 'regno' value is checked against the maximum pt_regs structure size, and then used to dereference it, which matches the initial part of a Spectre v1 (and Spectre v1.1) attack. The dereferenced value, then, is returned to userspace in the GETREGS case. This patch sanitizes 'regno' before using it to dereference pt_reg. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by:
Breno Leitao <leitao@debian.org> Acked-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
- 05 Feb, 2019 3 commits
-
-
Joel Stanley authored
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning is emitted: powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from `arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt' As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local symbols")[1], 32 bit targets can produce .branch_lt sections in their output. Include these symbols in the .data section as the ppc64 kernel does. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ceSigned-off-by:Joel Stanley <joel@jms.id.au> Reviewed-by:
Alan Modra <amodra@gmail.com> Signed-off-by:
-
Sam Bobroff authored
Currently, eeh_pe_reset_full() will only attempt to reset a PE more than once if activating the reset state and deactivating it both succeed, but later polling shows that it hasn't become active. Change this so that it will try up to three times for any reason other than an unrecoverable slot error and adjust the message generation so that it's clear weather the reset has ultimately succeeded or failed. This allows the reset to succeed in some situations where it would currently fail. Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by:
-
Sam Bobroff authored
Currently, the EEH recovery process considers passed-through devices as if they were not EEH-aware, which can cause them to be removed as part of recovery. Because device removal requires cooperation from the guest, this may lead to the process stalling or deadlocking. Also, if devices are removed on the host side, they will be removed from their IOMMU group, making recovery in the guest impossible. Therefore, alter the recovery process so that passed-through devices are not removed but are instead left frozen (and marked isolated) until the guest performs it's own recovery. If firmware thaws a passed-through PE because it's parent PE has been thawed (because it was not passed through), re-freeze it. Signed-off-by:
-
