summaryrefslogtreecommitdiff
path: root/drivers/iommu
AgeCommit message (Collapse)AuthorFilesLines
2016-04-21iommu/arm-smmu: Don't allocate resources for bypass domainsRobin Murphy1-1/+7
Until we get fully plumbed into of_iommu_configure, our default IOMMU_DOMAIN_DMA domains just bypass translation. Since we achieve that by leaving the stream table entries set to bypass instead of pointing at a translation context, the context bank we allocate for the domain is completely wasted. Context banks are typically a rather limited resource, so don't hog ones we don't need. Reported-by: Eric Auger <eric.auger@linaro.org> Tested-by: Eric Auger <eric.auger@linaro.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-21iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMAWill Deacon1-6/+8
Commit cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now") ignores requests to attach a device to the default domain since, without IOMMU-basked DMA ops available everywhere, the default domain will just lead to unexpected transaction faults being reported. Unfortunately, the way this was implemented on SMMUv2 causes a regression with VFIO PCI device passthrough under KVM on AMD Seattle. On this system, the host controller device is associated with both a pci_dev *and* a platform_device, and can therefore end up with duplicate SMR entries, resulting in a stream-match conflict at runtime. This patch amends the original fix so that attaching to IOMMU_DOMAIN_DMA is rejected even before configuring the SMRs. This restores the old behaviour for now, but we'll need to look at handing host controllers specially when we come to supporting the default domain fully. Reported-by: Eric Auger <eric.auger@linaro.org> Tested-by: Eric Auger <eric.auger@linaro.org> Tested-by: Yang Shi <yang.shi@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-11iommu/amd: Fix checking of pci dma aliasesJoerg Roedel1-11/+76
Commit 61289cb ('iommu/amd: Remove old alias handling code') removed the old alias handling code from the AMD IOMMU driver because this is now handled by the IOMMU core code. But this also removed the handling of PCI aliases, which is not handled by the core code. This caused issues with PCI devices that have hidden PCIe-to-PCI bridges that rewrite the request-id. Fix this bug by re-introducing some of the removed functions from commit 61289cbaf6c8 and add a alias field 'struct iommu_dev_data'. This field carrys the return value of the get_alias() function and uses that instead of the amd_iommu_alias_table[] array in the code. Fixes: 61289cbaf6c8 ('iommu/amd: Remove old alias handling code') Cc: stable@vger.kernel.org # v4.4+ Tested-by: Tomasz Golinski <tomaszg@math.uwb.edu.pl> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-07iommu/vt-d: Silence an uninitialized variable warningDan Carpenter1-1/+1
My static checker complains that "dma_alias" is uninitialized unless we are dealing with a pci device. This is true but harmless. Anyway, we can flip the condition around to silence the warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-07iommu/rockchip: Fix "is stall active" checkJohn Keeping1-4/+4
Since commit cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves") rk_iommu_is_stall_active() always returns false because the bitwise AND operates on the boolean flag promoted to an integer and a value that is either zero or BIT(2). Explicitly convert the right-hand value to a boolean so that both sides are guaranteed to be either zero or one. rk_iommu_is_paging_enabled() does not suffer from the same problem since RK_MMU_STATUS_PAGING_ENABLED is BIT(0), but let's apply the same change for consistency and to make it clear that it's correct without needing to lookup the value. Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves") Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-07iommu: Don't overwrite domain pointer when there is no default_domainJoerg Roedel1-1/+2
IOMMU drivers that do not support default domains, but make use of the the group->domain pointer can get that pointer overwritten with NULL on device add/remove. Make sure this can't happen by only overwriting the domain pointer when it is NULL. Cc: stable@vger.kernel.org # v4.4+ Fixes: 1228236de5f9 ('iommu: Move default domain allocation to iommu_group_get_for_dev()') Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-04-05iommu/dma: Restore scatterlist offsets correctlyRobin Murphy1-2/+2
With the change to stashing just the IOVA-page-aligned remainder of the CPU-page offset rather than the whole thing, the failure path in __invalidate_sg() also needs tweaking to account for that in the case of differing page sizes where the two offsets may not be equivalent. Similarly in __finalise_sg(), lest the architecture-specific wrappers later get the wrong address for cache maintenance on sync or unmap. Fixes: 164afb1d85b8 ("iommu/dma: Use correct offset in map_sg") Reported-by: Magnus Damm <damm+renesas@opensource.se> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Cc: stable@ver.kernel.org # v4.4+ Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-03-22Merge tag 'iommu-updates-v4.6' of ↵Linus Torvalds13-400/+2273
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull IOMMU updates from Joerg Roedel: - updates for the Exynos IOMMU driver to make use of default domains and to add support for the SYSMMU v5 - new Mediatek IOMMU driver - support for the ARMv7 short descriptor format in the io-pgtable code - default domain support for the ARM SMMU - couple of other small fixes all over the place * tag 'iommu-updates-v4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (41 commits) iommu/ipmmu-vmsa: Add r8a7795 DT binding iommu/mediatek: Check for NULL instead of IS_ERR() iommu/io-pgtable-armv7s: Fix kmem_cache_alloc() flags iommu/mediatek: Fix handling of of_count_phandle_with_args result iommu/dma: Fix NEED_SG_DMA_LENGTH dependency iommu/mediatek: Mark PM functions as __maybe_unused iommu/mediatek: Select ARM_DMA_USE_IOMMU iommu/exynos: Use proper readl/writel register interface iommu/exynos: Pointers are nto physical addresses dts: mt8173: Add iommu/smi nodes for mt8173 iommu/mediatek: Add mt8173 IOMMU driver memory: mediatek: Add SMI driver dt-bindings: mediatek: Add smi dts binding dt-bindings: iommu: Add binding for mediatek IOMMU iommu/ipmmu-vmsa: Use ARCH_RENESAS iommu/exynos: Support multiple attach_device calls iommu/exynos: Add Maintainers entry for Exynos SYSMMU driver iommu/exynos: Add support for v5 SYSMMU iommu/exynos: Update device tree documentation iommu/exynos: Add support for SYSMMU controller with bogus version reg ...
2016-03-21Merge branches 'arm/rockchip', 'arm/exynos', 'arm/smmu', 'arm/mediatek', ↵Joerg Roedel13-400/+2273
'arm/io-pgtable', 'arm/renesas' and 'core' into next
2016-03-21Merge branch 'mm-pkeys-for-linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 protection key support from Ingo Molnar: "This tree adds support for a new memory protection hardware feature that is available in upcoming Intel CPUs: 'protection keys' (pkeys). There's a background article at LWN.net: https://lwn.net/Articles/643797/ The gist is that protection keys allow the encoding of user-controllable permission masks in the pte. So instead of having a fixed protection mask in the pte (which needs a system call to change and works on a per page basis), the user can map a (handful of) protection mask variants and can change the masks runtime relatively cheaply, without having to change every single page in the affected virtual memory range. This allows the dynamic switching of the protection bits of large amounts of virtual memory, via user-space instructions. It also allows more precise control of MMU permission bits: for example the executable bit is separate from the read bit (see more about that below). This tree adds the MM infrastructure and low level x86 glue needed for that, plus it adds a high level API to make use of protection keys - if a user-space application calls: mmap(..., PROT_EXEC); or mprotect(ptr, sz, PROT_EXEC); (note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice this special case, and will set a special protection key on this memory range. It also sets the appropriate bits in the Protection Keys User Rights (PKRU) register so that the memory becomes unreadable and unwritable. So using protection keys the kernel is able to implement 'true' PROT_EXEC on x86 CPUs: without protection keys PROT_EXEC implies PROT_READ as well. Unreadable executable mappings have security advantages: they cannot be read via information leaks to figure out ASLR details, nor can they be scanned for ROP gadgets - and they cannot be used by exploits for data purposes either. We know about no user-space code that relies on pure PROT_EXEC mappings today, but binary loaders could start making use of this new feature to map binaries and libraries in a more secure fashion. There is other pending pkeys work that offers more high level system call APIs to manage protection keys - but those are not part of this pull request. Right now there's a Kconfig that controls this feature (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled (like most x86 CPU feature enablement code that has no runtime overhead), but it's not user-configurable at the moment. If there's any serious problem with this then we can make it configurable and/or flip the default" * 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (38 commits) x86/mm/pkeys: Fix mismerge of protection keys CPUID bits mm/pkeys: Fix siginfo ABI breakage caused by new u64 field x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA mm/core, x86/mm/pkeys: Add execute-only protection keys support x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags x86/mm/pkeys: Allow kernel to modify user pkey rights register x86/fpu: Allow setting of XSAVE state x86/mm: Factor out LDT init from context init mm/core, x86/mm/pkeys: Add arch_validate_pkey() mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits() x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU x86/mm/pkeys: Add Kconfig prompt to existing config option x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps x86/mm/pkeys: Dump PKRU with other kernel registers mm/core, x86/mm/pkeys: Differentiate instruction fetches x86/mm/pkeys: Optimize fault handling in access_error() mm/core: Do not enforce PKEY permissions on remote mm access um, pkeys: Add UML arch_*_access_permitted() methods mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys x86/mm/gup: Simplify get_user_pages() PTE bit handling ...
2016-03-02iommu/mediatek: Check for NULL instead of IS_ERR()Dan Carpenter1-3/+3
of_platform_device_create() returns NULL on error, it never returns error pointers. Fixes: 0df4fabe208d ('iommu/mediatek: Add mt8173 IOMMU driver') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-03-02iommu/io-pgtable-armv7s: Fix kmem_cache_alloc() flagsRobin Murphy1-1/+1
Whilst the default SLUB allocator happily just merges the original allocation flags from kmem_cache_create() with those passed through kmem_cache_alloc(), there is a code path in the SLAB allocator which will aggressively BUG_ON() if the cache was created with SLAB_CACHE_DMA but GFP_DMA is not specified for an allocation: kernel BUG at mm/slab.c:2536! Internal error: Oops - BUG: 0 [#1] SMP ARM Modules linked in:[ 1.299311] Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc6-koelsch-05892-ge7e45ad53ab6795e #2270 Hardware name: Generic R8A7791 (Flattened Device Tree) task: ef422040 ti: ef442000 task.ti: ef442000 PC is at cache_alloc_refill+0x2a0/0x530 LR is at _raw_spin_unlock+0x8/0xc ... [<c02c6928>] (cache_alloc_refill) from [<c02c6630>] (kmem_cache_alloc+0x7c/0xd4) [<c02c6630>] (kmem_cache_alloc) from [<c04444bc>] (__arm_v7s_alloc_table+0x5c/0x278) [<c04444bc>] (__arm_v7s_alloc_table) from [<c0444e1c>] (__arm_v7s_map.constprop.6+0x68/0x25c) [<c0444e1c>] (__arm_v7s_map.constprop.6) from [<c0445044>] (arm_v7s_map+0x34/0xa4) [<c0445044>] (arm_v7s_map) from [<c0c18ee4>] (arm_v7s_do_selftests+0x140/0x418) [<c0c18ee4>] (arm_v7s_do_selftests) from [<c0201760>] (do_one_initcall+0x100/0x1b4) [<c0201760>] (do_one_initcall) from [<c0c00d4c>] (kernel_init_freeable+0x120/0x1e8) [<c0c00d4c>] (kernel_init_freeable) from [<c067a364>] (kernel_init+0x8/0xec) [<c067a364>] (kernel_init) from [<c0206b68>] (ret_from_fork+0x14/0x2c) Code: 1a000003 e7f001f2 e3130001 0a000000 (e7f001f2) ---[ end trace 190f6f6b84352efd ]--- Keep the peace by adding GFP_DMA when allocating a table. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-03-01iommu/mediatek: Fix handling of of_count_phandle_with_args resultAndrzej Hajda1-2/+1
The function can return negative value so it should be assigned to signed variable. The patch changes also type of related i variable to make code more compact and coherent. The problem has been detected using patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-03-01iommu/vt-d: Use BUS_NOTIFY_REMOVED_DEVICE in hotplug pathJoerg Roedel2-4/+5
In the PCI hotplug path of the Intel IOMMU driver, replace the usage of the BUS_NOTIFY_DEL_DEVICE notifier, which is executed before the driver is unbound from the device, with BUS_NOTIFY_REMOVED_DEVICE, which runs after that. This fixes a kernel BUG being triggered in the VT-d code when the device driver tries to unmap DMA buffers and the VT-d driver already destroyed all mappings. Reported-by: Stefani Seibold <stefani@seibold.net> Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/amd: Detach device from domain before removalJoerg Roedel1-0/+4
Detach the device that is about to be removed from its domain (if it has one) to clear any related state like DTE entry and device's ATS state. Reported-by: Kelly Zytaruk <Kelly.Zytaruk@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/dma: Fix NEED_SG_DMA_LENGTH dependencyRobin Murphy1-1/+1
IOMMU_DMA does indeed depend on scatterlists having a DMA length, but the NEED_SG_DMA_LENGTH symbol should be selected, not depended upon. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/mediatek: Mark PM functions as __maybe_unusedArnd Bergmann1-2/+2
When CONFIG_PM is unset, we get a harmless warning for this driver: drivers/iommu/mtk_iommu.c:665:12: error: 'mtk_iommu_suspend' defined but not used [-Werror=unused-function] drivers/iommu/mtk_iommu.c:680:12: error: 'mtk_iommu_resume' defined but not used [-Werror=unused-function] Marking the functions as __maybe_unused gits rid of the two functions and lets the compiler silently drop the object code, while still doing syntax checking on them for build-time verification. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver") Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/mediatek: Select ARM_DMA_USE_IOMMUArnd Bergmann1-0/+1
The newly added Mediatek IOMMU driver uses the IOMMU_DMA infrastructure, but unlike other such drivers, it does not select 'ARM_DMA_USE_IOMMU', which is a prerequisite, leading to a link error: warning: (MTK_IOMMU) selects IOMMU_DMA which has unmet direct dependencies (IOMMU_SUPPORT && NEED_SG_DMA_LENGTH) drivers/iommu/built-in.o: In function `iommu_put_dma_cookie': mtk_iommu.c:(.text+0x11fe): undefined reference to `put_iova_domain' drivers/iommu/built-in.o: In function `iommu_dma_init_domain': mtk_iommu.c:(.text+0x1316): undefined reference to `init_iova_domain' drivers/iommu/built-in.o: In function `__iommu_dma_unmap': mtk_iommu.c:(.text+0x1380): undefined reference to `find_iova' This adds the same select that the other drivers have. On a related note, I wonder if we should just always select ARM_DMA_USE_IOMMU whenever any IOMMU driver is enabled. Are there any cases where we would enable an IOMMU but not use it? Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver") Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/exynos: Use proper readl/writel register interfaceMarek Szyprowski1-19/+19
Drivers should use generic readl/writel calls to access HW registers, so replace all __raw_readl/writel with generic version. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-29iommu/exynos: Pointers are nto physical addressesArnd Bergmann1-1/+1
The exynos iommu driver changed an incorrect cast from pointer to 'unsigned int' to an equally incorrect cast to a 'phys_addr_t', which results in an obvious compile-time error when phys_addr_t is wider than pointers are: drivers/iommu/exynos-iommu.c: In function 'alloc_lv2entry': drivers/iommu/exynos-iommu.c:918:32: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] The code does not actually want the physical address (which would involve using virt_to_phys()), but just checks the alignment, so we can change it to use a cast to uintptr_t instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 740a01eee9ad ("iommu/exynos: Add support for v5 SYSMMU") Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/amd: Apply workaround for ATS write permission checkJay Cornwall1-0/+29
The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's Guide omitted part of the BIOS IOMMU L2 register setup specification. Without this setup the IOMMU L2 does not fully respect write permissions when handling an ATS translation request. The IOMMU L2 will set PTE dirty bit when handling an ATS translation with write permission request, even when PTE RW bit is clear. This may occur by direct translation (which would cause a PPR) or by prefetch request from the ATC. This is observed in practice when the IOMMU L2 modifies a PTE which maps a pagecache page. The ext4 filesystem driver BUGs when asked to writeback these (non-modified) pages. Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not. Signed-off-by: Jay Cornwall <jay@jcornwall.me> Cc: <stable@vger.kernel.org> # v3.19+ Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/amd: Fix boot warning when device 00:00.0 is not iommu coveredSuravee Suthikulpanit1-12/+22
The setup code for the performance counters in the AMD IOMMU driver tests whether the counters can be written. It tests to setup a counter for device 00:00.0, which fails on systems where this particular device is not covered by the IOMMU. Fix this by not relying on device 00:00.0 but only on the IOMMU being present. Cc: stable@vger.kernel.org Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/mediatek: Add mt8173 IOMMU driverYong Wu3-0/+754
This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25Merge branch 'for-joerg/arm-smmu/updates' of ↵Joerg Roedel3-52/+78
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmu
2016-02-25iommu/ipmmu-vmsa: Use ARCH_RENESASSimon Horman1-1/+1
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Support multiple attach_device callsMarek Szyprowski1-32/+40
IOMMU core calls attach_device callback without detaching device from the previous domain. This patch adds support for such unballanced calls. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Add support for v5 SYSMMUMarek Szyprowski2-49/+140
This patch adds support for v5 of SYSMMU controller, found in Samsung Exynos 5433 SoCs. The main difference of v5 is support for 36-bit physical address space and some changes in register layout and core clocks hanging. This patch also adds support for ARM64 architecture, which is used by Exynos 5433 SoCs. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Add support for SYSMMU controller with bogus version regMarek Szyprowski1-1/+23
SYSMMU on some SoCs reports bogus values in VERSION register. Force hardware version to 1.0 for such controllers. This patch also moves reading version register to driver's probe() function. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Unify code for fldp cache invalidationMarek Szyprowski1-9/+4
This patch simplifies the code for handling of flpdcache invalidation. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Refactor init config codeMarek Szyprowski1-16/+9
This patch rewrites sysmmu_init_config function to make it easier to read and understand. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Refactor fault handling codeMarek Szyprowski1-68/+41
This patch provides a new implementation for page fault handing code. The new implementation is ready for future extensions. No functional changes have been made. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Refactor code (no direct register access)Marek Szyprowski1-21/+19
This patch changes some internal functions to have access to the state of sysmmu device instead of having only it's registers. This will make the code ready for future extensions. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Simplify master clock operationsMarek Szyprowski1-20/+12
All clock API function can be called on NULL clock, so simplify code avoid checking of master clock presence. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Remove ARM-specific cache flush interfaceMarek Szyprowski1-25/+49
This patch replaces custom ARM-specific code for performing CPU cache flush operations with generic code based on DMA-mapping. Domain managing code is independent of particular SYSMMU device, so the first registered SYSMMU device is used for DMA-mapping calls. This simplification works fine because all SYSMMU controllers are in the same address space (where DMA address equals physical address) and the DMA-mapping calls are done mainly to flush CPU cache to make changes visible to SYSMMU controllers. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Add support for IOMMU_DOMAIN_DMA domain typeMarek Szyprowski1-4/+15
This patch adds support for DMA domain type. Such domain have DMA cookie prepared and can be used by generic DMA-IOMMU glue layer. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu/exynos: Rework iommu group initializationMarek Szyprowski1-11/+16
This patch replaces custom code in add_device implementation with iommu_group_get_for_dev() call and provides the needed callback. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25iommu: Fix second argument of trace_map() to report correct paddrYoshihiro Shimoda1-1/+2
Since iommu_map() code added pgsize value to the paddr, trace_map() used wrong paddr. So, this patch adds "orig_paddr" value in the iommu_map() to use for the trace_map(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-02-25Merge branch 'for-joerg/io-pgtable' of ↵Joerg Roedel6-17/+941
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/io-pgtable
2016-02-18mm/core: Do not enforce PKEY permissions on remote mm accessDave Hansen1-0/+1
We try to enforce protection keys in software the same way that we do in hardware. (See long example below). But, we only want to do this when accessing our *own* process's memory. If GDB set PKRU[6].AD=1 (disable access to PKEY 6), then tried to PTRACE_POKE a target process which just happened to have some mprotect_pkey(pkey=6) memory, we do *not* want to deny the debugger access to that memory. PKRU is fundamentally a thread-local structure and we do not want to enforce it on access to _another_ thread's data. This gets especially tricky when we have workqueues or other delayed-work mechanisms that might run in a random process's context. We can check that we only enforce pkeys when operating on our *own* mm, but delayed work gets performed when a random user context is active. We might end up with a situation where a delayed-work gup fails when running randomly under its "own" task but succeeds when running under another process. We want to avoid that. To avoid that, we use the new GUP flag: FOLL_REMOTE and add a fault flag: FAULT_FLAG_REMOTE. They indicate that we are walking an mm which is not guranteed to be the same as current->mm and should not be subject to protection key enforcement. Thanks to Jerome Glisse for pointing out this scenario. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Boaz Harrosh <boaz@plexistor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Chinner <dchinner@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Dominik Dingel <dingel@linux.vnet.ibm.com> Cc: Dominik Vogt <vogt@linux.vnet.ibm.com> Cc: Eric B Munson <emunson@akamai.com> Cc: Geliang Tang <geliangtang@163.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Low <jason.low2@hp.com> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Shachar Raindel <raindel@mellanox.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xie XiuQi <xiexiuqi@huawei.com> Cc: iommu@lists.linux-foundation.org Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-s390@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-02-18iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for nowWill Deacon2-1/+13
Until all upstream devices have their DMA ops swizzled to point at the SMMU, we need to treat the IOMMU_DOMAIN_DMA domain as bypass to avoid putting devices into an empty address space when detaching from VFIO. Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-18iommu/arm-smmu: Don't fail device attach if already attached to a domainWill Deacon2-40/+26
The ARM SMMU attach_dev implementations returns -EEXIST if the device being attached is already attached to a domain. This doesn't play nicely with the default domain, resulting in splats such as: WARNING: at drivers/iommu/iommu.c:1257 Modules linked in: CPU: 3 PID: 1939 Comm: virtio-net-tx Tainted: G S 4.5.0-rc4+ #1 Hardware name: FVP Base (DT) task: ffffffc87a9d0000 ti: ffffffc07a278000 task.ti: ffffffc07a278000 PC is at __iommu_detach_group+0x68/0xe8 LR is at __iommu_detach_group+0x48/0xe8 This patch fixes the problem by forcefully detaching the device from its old domain, if present, when attaching to a new one. The unused ->detach_dev callback is also removed the iommu_ops structures. Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-18iommu/arm-smmu: Allow disabling unmatched stream bypassRobin Murphy1-8/+16
Borrow the disable_bypass parameter from the SMMUv3 driver as a handy debugging/security feature so that unmatched stream IDs (i.e. devices not attached to an IOMMU domain) may be configured to fault. Rather than introduce unsightly inconsistency, or repeat the existing unnecessary use of module_param_named(), fix that as well in passing. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-18of: iommu: Increment DT node refcount in of_iommu_set_ops()Anup Patel1-0/+1
We are saving pointer to iommu DT node in of_iommu_set_ops() hence we should increment DT node ref count. Reviewed-by: Ray Jui <rjui@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Anup Patel <anup.patel@broadcom.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-18iommu/arm-smmu: Support DMA-API domainsRobin Murphy2-2/+18
With DMA mapping ops provided by the iommu-dma code, only a minimal contribution from the IOMMU driver is needed to create a suitable DMA-API domain for them to use. Implement this for the ARM SMMUs. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-18iommu/arm-smmu: Treat all device transactions as unprivilegedRobin Murphy1-1/+4
The IOMMU API has no concept of privilege so assumes all devices and mappings are equal, and indeed most non-CPU master devices on an AMBA interconnect make little use of the attribute bits on the bus thus by default perform unprivileged data accesses. Some devices, however, believe themselves more equal than others, such as programmable DMA controllers whose 'master' thread issues bus transactions marked as privileged instruction fetches, while the data accesses of its channel threads (under the control of Linux, at least) are marked as unprivileged. This poses a problem for implementing the DMA API on an IOMMU conforming to ARM VMSAv8, under which a page that is unprivileged-writeable is also implicitly privileged-execute-never. Given that, there is no one set of attributes with which iommu_map() can implement, say, dma_alloc_coherent() that will allow every possible type of access without something running into unexecepted permission faults. Fortunately the SMMU architecture provides a means to mitigate such issues by overriding the incoming attributes of a transaction; make use of that to strip the privileged/unprivileged status off incoming transactions, leaving just the instruction/data dichotomy which the IOMMU API does at least understand; Four states good, two states better. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-17iommu/io-pgtable: Rationalise quirk handlingRobin Murphy3-6/+34
As the number of io-pgtable implementations grows beyond 1, it's time to rationalise the quirks mechanism before things have a chance to start getting really ugly and out-of-hand. To that end: - Indicate exactly which quirks each format can/does support. - Fail creating a table if a caller wants unsupported quirks. - Properly document where each quirk applies and why. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-17iommu/io-pgtable: Avoid redundant TLB syncsRobin Murphy1-1/+8
In certain unmapping situations it is quite possible to end up issuing back-to-back TLB synchronisations, which at best is a waste of time and effort, and at worst causes some hardware to get rather confused. Whilst the pagetable implementations, or the IOMMU drivers, or both, could keep track of things to avoid this happening, it seems to make the most sense to prevent code duplication and add some simple state tracking in the common interface between the two. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-17iommu/io-pgtable: Add helper functions for TLB opsRobin Murphy4-41/+46
Add some simple wrappers to avoid having the guts of the TLB operations spilled all over the page table implementations, and to provide a point to implement extra common functionality. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-17iommu/io-pgtable: Add ARMv7 short descriptor supportRobin Murphy5-1/+885
Add a nearly-complete ARMv7 short descriptor implementation, omitting only a few legacy and CPU-centric aspects which shouldn't be necessary for IOMMU API use anyway. Reviewed-by: Yong Wu <yong.wu@mediatek.com> Tested-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-16Merge tag 'for-linus-20160216' of git://git.infradead.org/intel-iommuLinus Torvalds3-8/+33
Pull IOMMU SVM fixes from David Woodhouse: "Minor register size and interrupt acknowledgement fixes which only showed up in testing on newer hardware, but mostly a fix to the MM refcount handling to prevent a recursive refcount issue when mmap() is used on the file descriptor associated with a bound PASID" * tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu: iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-22 11:15:31 +0300