BMC/Intel-BMC/linux.git/drivers/iommu, branch dev-4.6

iommu/arm-smmu: Don't allocate resources for bypass domains

2016-04-21T14:47:32+00:00

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 Tested-by: Eric Auger Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Joerg Roedel

iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMA

2016-04-21T14:47:32+00:00

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 Tested-by: Eric Auger Tested-by: Yang Shi Signed-off-by: Will Deacon Signed-off-by: Joerg Roedel

iommu/amd: Fix checking of pci dma aliases

2016-04-11T14:07:51+00:00

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 Signed-off-by: Joerg Roedel

iommu/vt-d: Silence an uninitialized variable warning

2016-04-07T12:51:47+00:00

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 Signed-off-by: Joerg Roedel

iommu/rockchip: Fix "is stall active" check

2016-04-07T12:50:18+00:00

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 Reviewed-by: Heiko Stuebner Tested-by: Tomeu Vizoso Signed-off-by: Joerg Roedel

iommu: Don't overwrite domain pointer when there is no default_domain

2016-04-07T12:33:03+00:00

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

iommu/dma: Restore scatterlist offsets correctly

2016-04-05T13:14:05+00:00

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 Signed-off-by: Robin Murphy Cc: stable@ver.kernel.org # v4.4+ Signed-off-by: Joerg Roedel

Merge tag 'iommu-updates-v4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2016-03-22T18:57:43+00:00

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 ...

Merge branches 'arm/rockchip', 'arm/exynos', 'arm/smmu', 'arm/mediatek', 'arm/io-pgtable', 'arm/renesas' and 'core' into next

2016-03-21T13:58:47+00:00

Merge branch 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2016-03-21T02:08:56+00:00

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 ...