AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-25 07:02:59 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
45f8472fa2
linux_dsm_epyc7002/drivers/iommu/Kconfig

405 lines
12 KiB
Plaintext
Raw Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 19:07:45 +07:00
# SPDX-License-Identifier: GPL-2.0-only
iommu/iova: Allow compiling the library without IOMMU support Drivers such as the Intel IPU3 ImgU driver use the IOVA library to manage the device's own virtual address space while not implementing the IOMMU API. Currently the IOVA library is only compiled if the IOMMU support is enabled, resulting into a failure during linking due to missing symbols. Fix this by defining IOVA library Kconfig bits independently of IOMMU support configuration, and descending to the iommu directory unconditionally during the build. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-03 04:16:57 +07:00
# The IOVA library may also be used by non-IOMMU_API users
config IOMMU_IOVA
tristate
iommu: Add I/O ASID allocator Some devices might support multiple DMA address spaces, in particular those that have the PCI PASID feature. PASID (Process Address Space ID) allows to share process address spaces with devices (SVA), partition a device into VM-assignable entities (VFIO mdev) or simply provide multiple DMA address space to kernel drivers. Add a global PASID allocator usable by different drivers at the same time. Name it I/O ASID to avoid confusion with ASIDs allocated by arch code, which are usually a separate ID space. The IOASID space is global. Each device can have its own PASID space, but by convention the IOMMU ended up having a global PASID space, so that with SVA, each mm_struct is associated to a single PASID. The allocator is primarily used by IOMMU subsystem but in rare occasions drivers would like to allocate PASIDs for devices that aren't managed by an IOMMU, using the same ID space as IOMMU. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-03 02:42:41 +07:00
# The IOASID library may also be used by non-IOMMU_API users
config IOASID
tristate
drivers: iommu: move to a dedicated folder Create a dedicated folder for iommu drivers, and move the base iommu implementation over there. Grouping the various iommu drivers in a single location will help finding similar problems shared by different platforms, so they could be solved once, in the iommu framework, instead of solved differently (or duplicated) in each driver. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-02 06:48:05 +07:00
# IOMMU_API always gets selected by whoever wants it.
config IOMMU_API
bool
msm: iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-02 07:20:08 +07:00
iommu: Move iommu Kconfig entries to submenu For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-14 20:51:54 +07:00
menuconfig IOMMU_SUPPORT
bool "IOMMU Hardware Support"
iommu: Disable on !MMU builds A lot of the IOMMU support code does not build if the CPU does not have an MMU itself, and it's not clear if there is any use case for it, so let's just disable it and wait for anybody to need it. This avoids randconfig errors like ../arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap': ../arch/arm/mm/dma-mapping.c:1278:34: error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function) area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP, ^ ../arch/arm/mm/dma-mapping.c:1278:34: note: each undeclared identifier is reported only once for each function it appears in ../arch/arm/mm/dma-mapping.c: In function '__atomic_get_pages': ../arch/arm/mm/dma-mapping.c:1358:27: error: 'atomic_pool' undeclared (first use in this function) struct dma_pool *pool = &atomic_pool; Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-01-28 21:45:53 +07:00
depends on MMU
iommu: Move iommu Kconfig entries to submenu For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-14 20:51:54 +07:00
default y
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-13 23:50:22 +07:00
help
iommu: Move iommu Kconfig entries to submenu For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-14 20:51:54 +07:00
Say Y here if you want to compile device drivers for IO Memory
Management Units into the kernel. These devices usually allow to
remap DMA requests and/or remap interrupts from other devices on the
system.
if IOMMU_SUPPORT
iommu: introduce generic page table allocation framework This patch introduces a generic framework for allocating page tables for an IOMMU. There are a number of reasons we want to do this: - It avoids duplication of complex table management code in IOMMU drivers that use the same page table format - It removes any coupling with the CPU table format (and even the architecture!) - It defines an API for IOMMU TLB maintenance Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:16:49 +07:00
menu "Generic IOMMU Pagetable Support"
# Selected by the actual pagetable implementations
config IOMMU_IO_PGTABLE
bool
iommu: add ARM LPAE page table allocator A number of IOMMUs found in ARM SoCs can walk architecture-compatible page tables. This patch adds a generic allocator for Stage-1 and Stage-2 v7/v8 long-descriptor page tables. 4k, 16k and 64k pages are supported, with up to 4-levels of walk to cover a 48-bit address space. Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:18:23 +07:00
config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
iommu: Remove depends on HAS_DMA in case of platform dependency Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-04-18 00:49:09 +07:00
depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
iommu: add ARM LPAE page table allocator A number of IOMMUs found in ARM SoCs can walk architecture-compatible page tables. This patch adds a generic allocator for Stage-1 and Stage-2 v7/v8 long-descriptor page tables. 4k, 16k and 64k pages are supported, with up to 4-levels of walk to cover a 48-bit address space. Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:18:23 +07:00
help
Enable support for the ARM long descriptor pagetable format.
This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
sizes at both stage-1 and stage-2, as well as address spaces
up to 48-bits in size.
iommu: add self-consistency tests to ARM LPAE IO page table allocator This patch adds a series of basic self-consistency tests to the ARM LPAE IO page table allocator that exercise corner cases in map/unmap, as well as testing all valid configurations of pagesize, ias and stage. Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-18 06:31:12 +07:00
config IOMMU_IO_PGTABLE_LPAE_SELFTEST
bool "LPAE selftests"
depends on IOMMU_IO_PGTABLE_LPAE
help
Enable self-tests for LPAE page table allocator. This performs
a series of page-table consistency checks during boot.
If unsure, say N here.
iommu/io-pgtable: Add ARMv7 short descriptor support 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-01-27 00:13:13 +07:00
config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
iommu: Remove depends on HAS_DMA in case of platform dependency Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-04-18 00:49:09 +07:00
depends on ARM || ARM64 || COMPILE_TEST
iommu/io-pgtable: Add ARMv7 short descriptor support 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-01-27 00:13:13 +07:00
help
Enable support for the ARM Short-descriptor pagetable format.
This supports 32-bit virtual and physical addresses mapped using
2-level tables with 4KB pages/1MB sections, and contiguous entries
for 64KB pages/16MB supersections if indicated by the IOMMU driver.
config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
bool "ARMv7s selftests"
depends on IOMMU_IO_PGTABLE_ARMV7S
help
Enable self-tests for ARMv7s page table allocator. This performs
a series of page-table consistency checks during boot.
If unsure, say N here.
iommu: introduce generic page table allocation framework This patch introduces a generic framework for allocating page tables for an IOMMU. There are a number of reasons we want to do this: - It avoids duplication of complex table management code in IOMMU drivers that use the same page table format - It removes any coupling with the CPU table format (and even the architecture!) - It defines an API for IOMMU TLB maintenance Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:16:49 +07:00
endmenu
iommu: Enable debugfs exposure of IOMMU driver internals Provide base enablement for using debugfs to expose internal data of an IOMMU driver. When called, create the /sys/kernel/debug/iommu directory. Emit a strong warning at boot time to indicate that this feature is enabled. This function is called from iommu_init, and creates the initial DebugFS directory. Drivers may then call iommu_debugfs_new_driver_dir() to instantiate a device-specific directory to expose internal data. It will return a pointer to the new dentry structure created in /sys/kernel/debug/iommu, or NULL in the event of a failure. Since the IOMMU driver can not be removed from the running system, there is no need for an "off" function. Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-06-13 04:41:21 +07:00
config IOMMU_DEBUGFS
bool "Export IOMMU internals in DebugFS"
depends on DEBUG_FS
help
Allows exposure of IOMMU device internals. This option enables
the use of debugfs by IOMMU drivers as required. Devices can,
at initialization time, cause the IOMMU code to create a top-level
debug/iommu directory, and then populate a subdirectory with
entries as required.
iommu: Add config option to set passthrough as default This allows the default behavior to be controlled by a kernel config option instead of changing the commandline for the kernel to include "iommu.passthrough=on" or "iommu=pt" on machines where this is desired. Likewise, for machines where this config option is enabled, it can be disabled at boot time with "iommu.passthrough=off" or "iommu=nopt". Also corrected iommu=pt documentation for IA-64, since it has no code that parses iommu= at all. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-07-21 01:02:23 +07:00
config IOMMU_DEFAULT_PASSTHROUGH
bool "IOMMU passthrough by default"
depends on IOMMU_API
iommu: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-21 10:19:30 +07:00
help
iommu: Add config option to set passthrough as default This allows the default behavior to be controlled by a kernel config option instead of changing the commandline for the kernel to include "iommu.passthrough=on" or "iommu=pt" on machines where this is desired. Likewise, for machines where this config option is enabled, it can be disabled at boot time with "iommu.passthrough=off" or "iommu=nopt". Also corrected iommu=pt documentation for IA-64, since it has no code that parses iommu= at all. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-07-21 01:02:23 +07:00
Enable passthrough by default, removing the need to pass in
iommu.passthrough=on or iommu=pt through command line. If this
is enabled, you can still disable with iommu.passthrough=off
or iommu=nopt depending on the architecture.
If unsure, say N here.
iommu: Add DMA window parser, of_get_dma_window() This code was based on: "arch/microblaze/kernel/prom_parse.c" "arch/powerpc/kernel/prom_parse.c" Can replace "of_parse_dma_window()" in the above. This supports different formats flexibly. "prefix" can be configured if any. "busno" and "index" are optionally specified. Set NULL and 0 if not used. Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-06-25 18:23:54 +07:00
config OF_IOMMU
iommu: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-21 10:19:30 +07:00
def_bool y
depends on OF && IOMMU_API
iommu: Add DMA window parser, of_get_dma_window() This code was based on: "arch/microblaze/kernel/prom_parse.c" "arch/powerpc/kernel/prom_parse.c" Can replace "of_parse_dma_window()" in the above. This supports different formats flexibly. "prefix" can be configured if any. "busno" and "index" are optionally specified. Set NULL and 0 if not used. Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-06-25 18:23:54 +07:00
iommu: Implement common IOMMU ops for DMA mapping Taking inspiration from the existing arch/arm code, break out some generic functions to interface the DMA-API to the IOMMU-API. This will do the bulk of the heavy lifting for IOMMU-backed dma-mapping. Since associating an IOVA allocator with an IOMMU domain is a fairly common need, rather than introduce yet another private structure just to do this for ourselves, extend the top-level struct iommu_domain with the notion. A simple opaque cookie allows reuse by other IOMMU API users with their various different incompatible allocator types. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-10-02 02:13:58 +07:00
# IOMMU-agnostic DMA-mapping layer
config IOMMU_DMA
bool
dma-mapping: make support for dma ops optional Avoid the overhead of the dma ops support for tiny builds that only use the direct mapping. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2020-07-08 14:30:00 +07:00
select DMA_OPS
iommu: Implement common IOMMU ops for DMA mapping Taking inspiration from the existing arch/arm code, break out some generic functions to interface the DMA-API to the IOMMU-API. This will do the bulk of the heavy lifting for IOMMU-backed dma-mapping. Since associating an IOVA allocator with an IOMMU domain is a fairly common need, rather than introduce yet another private structure just to do this for ourselves, extend the top-level struct iommu_domain with the notion. A simple opaque cookie allows reuse by other IOMMU API users with their various different incompatible allocator types. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-10-02 02:13:58 +07:00
select IOMMU_API
select IOMMU_IOVA
iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts On RT, iommu_dma_map_msi_msg() may be called from non-preemptible context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock (they can sleep on RT). iommu_dma_map_msi_msg() is used to map the MSI page in the IOMMU PT and update the MSI message with the IOVA. Only the part to lookup for the MSI page requires to be called in preemptible context. As the MSI page cannot change over the lifecycle of the MSI interrupt, the lookup can be cached and re-used later on. iomma_dma_map_msi_msg() is now split in two functions: - iommu_dma_prepare_msi(): This function will prepare the mapping in the IOMMU and store the cookie in the structure msi_desc. This function should be called in preemptible context. - iommu_dma_compose_msi_msg(): This function will update the MSI message with the IOVA when the device is behind an IOMMU. Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-05-01 20:58:19 +07:00
select IRQ_MSI_IOMMU
iommu/dma: Fix NEED_SG_DMA_LENGTH dependency 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-29 18:13:39 +07:00
select NEED_SG_DMA_LENGTH
iommu: Implement common IOMMU ops for DMA mapping Taking inspiration from the existing arch/arm code, break out some generic functions to interface the DMA-API to the IOMMU-API. This will do the bulk of the heavy lifting for IOMMU-backed dma-mapping. Since associating an IOVA allocator with an IOMMU domain is a fairly common need, rather than introduce yet another private structure just to do this for ourselves, extend the top-level struct iommu_domain with the notion. A simple opaque cookie allows reuse by other IOMMU API users with their various different incompatible allocator types. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-10-02 02:13:58 +07:00
iommu/fsl: Freescale PAMU driver and iommu implementation. Following is a brief description of the PAMU hardware: PAMU determines what action to take and whether to authorize the action on the basis of the memory address, a Logical IO Device Number (LIODN), and PAACT table (logically) indexed by LIODN and address. Hardware devices which need to access memory must provide an LIODN in addition to the memory address. Peripheral Access Authorization and Control Tables (PAACTs) are the primary data structures used by PAMU. A PAACT is a table of peripheral access authorization and control entries (PAACE).Each PAACE defines the range of I/O bus address space that is accessible by the LIOD and the associated access capabilities. There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT (SPAACT).A given physical I/O device may be able to act as one or more independent logical I/O devices (LIODs). Each such logical I/O device is assigned an identifier called logical I/O device number (LIODN). A LIODN is allocated a contiguous portion of the I/O bus address space called the DSA window for performing DSA operations. The DSA window may optionally be divided into multiple sub-windows, each of which may be used to map to a region in system storage space. The first sub-window is referred to as the primary sub-window and the remaining are called secondary sub-windows. This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) has been derived from the work done by Ashish Kalra and Timur Tabi. [For iommu group support] Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Timur Tabi <timur@tabi.org> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-07-15 11:50:57 +07:00
config FSL_PAMU
bool "Freescale IOMMU support"
iommu/pamu: Let PAMU depend on PCI The driver does not compile when PCI is not selected, so make it depend on it. Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-08-09 20:00:36 +07:00
depends on PCI
iommu/pamu: Make driver depend on CONFIG_PHYS_64BIT Certain address calculations in the driver make the assumption that phys_addr_t and dma_addr_t are 64 bit wide. Force this by depending on CONFIG_PHYS_64BIT to be set. Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-08-09 20:04:47 +07:00
depends on PHYS_64BIT
powerpc: Fix incorrect PPC32 PAMU dependency The Freescale PAMU can be enabled on both 32 and 64-bit Power chips. Commit 477ab7a19ce restricted PAMU to PPC32. PPC covers both. Signed-off-by: Andy Fleming <afleming@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-03-17 11:15:44 +07:00
depends on PPC_E500MC || (COMPILE_TEST && PPC)
iommu/fsl: Freescale PAMU driver and iommu implementation. Following is a brief description of the PAMU hardware: PAMU determines what action to take and whether to authorize the action on the basis of the memory address, a Logical IO Device Number (LIODN), and PAACT table (logically) indexed by LIODN and address. Hardware devices which need to access memory must provide an LIODN in addition to the memory address. Peripheral Access Authorization and Control Tables (PAACTs) are the primary data structures used by PAMU. A PAACT is a table of peripheral access authorization and control entries (PAACE).Each PAACE defines the range of I/O bus address space that is accessible by the LIOD and the associated access capabilities. There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT (SPAACT).A given physical I/O device may be able to act as one or more independent logical I/O devices (LIODs). Each such logical I/O device is assigned an identifier called logical I/O device number (LIODN). A LIODN is allocated a contiguous portion of the I/O bus address space called the DSA window for performing DSA operations. The DSA window may optionally be divided into multiple sub-windows, each of which may be used to map to a region in system storage space. The first sub-window is referred to as the primary sub-window and the remaining are called secondary sub-windows. This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) has been derived from the work done by Ashish Kalra and Timur Tabi. [For iommu group support] Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Timur Tabi <timur@tabi.org> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-07-15 11:50:57 +07:00
select IOMMU_API
select GENERIC_ALLOCATOR
help
Freescale PAMU support. PAMU is the IOMMU present on Freescale QorIQ platforms.
PAMU can authorize memory access, remap the memory address, and remap I/O
transaction types.
msm: iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-02 07:20:08 +07:00
# MSM IOMMU support
config MSM_IOMMU
bool "MSM IOMMU Support"
iommu: Make more drivers depend on COMPILE_TEST For easier compile testing of these iommu drivers. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-01-20 22:13:33 +07:00
depends on ARM
depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
msm: iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-02 07:20:08 +07:00
select IOMMU_API
iommu/msm: use generic ARMV7S short descriptor pagetable ops This iommu uses the armv7 short descriptor format. So use the generic ARMV7S pagetable ops instead of rewriting the same stuff in the driver. Signed-off-by: Sricharan R <sricharan@codeaurora.org> Tested-by: Archit Taneja <architt@codeaurora.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-06-13 18:36:06 +07:00
select IOMMU_IO_PGTABLE_ARMV7S
msm: iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-02 07:20:08 +07:00
help
Support for the IOMMUs found on certain Qualcomm SOCs.
These IOMMUs allow virtualization of the address space used by most
cores within the multimedia subsystem.
If unsure, say N here.
iommu/amd: Move Kconfig and Makefile bits down into amd directory Move AMD Kconfig and Makefile bits down into the amd directory with the rest of the AMD specific files. Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Link: https://lore.kernel.org/r/20200630200636.48600-3-jsnitsel@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-01 03:06:36 +07:00
source "drivers/iommu/amd/Kconfig"
iommu/vt-d: Move Kconfig and Makefile bits down into intel directory Move Intel Kconfig and Makefile bits down into intel directory with the rest of the Intel specific files. Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20200630200636.48600-2-jsnitsel@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-01 03:06:35 +07:00
source "drivers/iommu/intel/Kconfig"
iommu/vt-d: Add Kconfig option to enable/disable scalable mode This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON to make it easier for distributions to enable or disable the Intel IOMMU scalable mode by default during kernel build. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-01-02 07:18:02 +07:00
iommu: Rename the DMAR and INTR_REMAP config options Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent with the other IOMMU options. Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the irq subsystem name. And define the CONFIG_DMAR_TABLE for the common ACPI DMAR routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: yinghai@kernel.org Cc: youquan.song@intel.com Cc: joerg.roedel@amd.com Cc: tony.luck@intel.com Cc: dwmw2@infradead.org Link: http://lkml.kernel.org/r/20110824001456.558630224@sbsiddha-desk.sc.intel.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-08-24 07:05:25 +07:00
config IRQ_REMAP
drivers/iommu: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Joerg Roedel <joerg.roedel@amd.com> CC: Hiroshi DOYU <hdoyu@nvidia.com> CC: Jiri Kosina <jkosina@suse.cz> CC: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17 09:53:39 +07:00
bool "Support for Interrupt Remapping"
depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
iommu: Rename the DMAR and INTR_REMAP config options Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent with the other IOMMU options. Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the irq subsystem name. And define the CONFIG_DMAR_TABLE for the common ACPI DMAR routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: yinghai@kernel.org Cc: youquan.song@intel.com Cc: joerg.roedel@amd.com Cc: tony.luck@intel.com Cc: dwmw2@infradead.org Link: http://lkml.kernel.org/r/20110824001456.558630224@sbsiddha-desk.sc.intel.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-08-24 07:05:25 +07:00
select DMAR_TABLE
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-13 23:50:22 +07:00
help
x86/ia64: intel-iommu: move to drivers/iommu/ This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge() has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled in this patch, too. As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it. Compile-tested on x86_64. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-11 01:42:27 +07:00
Supports Interrupt remapping for IO-APIC and MSI devices.
To use x2apic mode in the CPU's which support x2APIC enhancements or
to support platforms with CPU's having > 8 bit APIC ID, say Y.
iommu: Move iommu Kconfig entries to submenu For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-14 20:51:54 +07:00
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
# OMAP IOMMU support
config OMAP_IOMMU
bool "OMAP IOMMU Support"
iommu: Make more drivers depend on COMPILE_TEST For easier compile testing of these iommu drivers. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-01-20 22:13:33 +07:00
depends on ARCH_OMAP2PLUS || COMPILE_TEST
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
select IOMMU_API
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-13 23:50:22 +07:00
help
break kconfig dependency loop After adding virtio-gpu I get this funky kconfig dependency loop. scripts/kconfig/conf --oldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3 drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2 drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the loop, which looks like the best way to handle it to me. Updated OMAP_IOMMU help text accordingly. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-11 15:17:00 +07:00
The OMAP3 media platform drivers depend on iommu support,
if you need them say Y here.
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
config OMAP_IOMMU_DEBUG
iommu/omap: Integrate omap-iommu-debug into omap-iommu The debugfs support for OMAP IOMMU is currently implemented as a module, warranting certain OMAP-specific IOMMU API to be exported. The OMAP IOMMU, when enabled, can only be built-in into the kernel, so integrate the OMAP IOMMU debug module into the OMAP IOMMU driver. This helps in eliminating the need to export most of the current OMAP IOMMU API. The following are the main changes: - The debugfs directory and entry creation logic is reversed, the calls are invoked by the OMAP IOMMU driver now. - The current iffy circular logic of adding IOMMU archdata to the IOMMU devices itself to get a pointer to the omap_iommu object in the debugfs support code is replaced by directly using the omap_iommu structure while creating the debugfs entries. - The debugfs root directory is renamed from the generic name "iommu" to a specific name "omap_iommu". - Unneeded headers have also been cleaned up while at this. - There will no longer be a omap-iommu-debug.ko module after this patch. - The OMAP_IOMMU_DEBUG Kconfig option is converted to boolean only, the OMAP IOMMU debugfs support is built alongside the OMAP IOMMU driver only when this option is enabled. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-10-23 05:22:30 +07:00
bool "Export OMAP IOMMU internals in DebugFS"
depends on OMAP_IOMMU && DEBUG_FS
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-13 23:50:22 +07:00
help
iommu/omap: Integrate omap-iommu-debug into omap-iommu The debugfs support for OMAP IOMMU is currently implemented as a module, warranting certain OMAP-specific IOMMU API to be exported. The OMAP IOMMU, when enabled, can only be built-in into the kernel, so integrate the OMAP IOMMU debug module into the OMAP IOMMU driver. This helps in eliminating the need to export most of the current OMAP IOMMU API. The following are the main changes: - The debugfs directory and entry creation logic is reversed, the calls are invoked by the OMAP IOMMU driver now. - The current iffy circular logic of adding IOMMU archdata to the IOMMU devices itself to get a pointer to the omap_iommu object in the debugfs support code is replaced by directly using the omap_iommu structure while creating the debugfs entries. - The debugfs root directory is renamed from the generic name "iommu" to a specific name "omap_iommu". - Unneeded headers have also been cleaned up while at this. - There will no longer be a omap-iommu-debug.ko module after this patch. - The OMAP_IOMMU_DEBUG Kconfig option is converted to boolean only, the OMAP IOMMU debugfs support is built alongside the OMAP IOMMU driver only when this option is enabled. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-10-23 05:22:30 +07:00
Select this to see extensive information about
the internal state of OMAP IOMMU in debugfs.
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
iommu/omap: Integrate omap-iommu-debug into omap-iommu The debugfs support for OMAP IOMMU is currently implemented as a module, warranting certain OMAP-specific IOMMU API to be exported. The OMAP IOMMU, when enabled, can only be built-in into the kernel, so integrate the OMAP IOMMU debug module into the OMAP IOMMU driver. This helps in eliminating the need to export most of the current OMAP IOMMU API. The following are the main changes: - The debugfs directory and entry creation logic is reversed, the calls are invoked by the OMAP IOMMU driver now. - The current iffy circular logic of adding IOMMU archdata to the IOMMU devices itself to get a pointer to the omap_iommu object in the debugfs support code is replaced by directly using the omap_iommu structure while creating the debugfs entries. - The debugfs root directory is renamed from the generic name "iommu" to a specific name "omap_iommu". - Unneeded headers have also been cleaned up while at this. - There will no longer be a omap-iommu-debug.ko module after this patch. - The OMAP_IOMMU_DEBUG Kconfig option is converted to boolean only, the OMAP IOMMU debugfs support is built alongside the OMAP IOMMU driver only when this option is enabled. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-10-23 05:22:30 +07:00
Say N unless you know you need this.
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
iommu/rockchip: rk3288 iommu driver The rk3288 has several iommus. Each iommu belongs to a single master device. There is one device (ISP) that has two slave iommus, but that case is not yet supported by this driver. At subsys init, the iommu driver registers itself as the iommu driver for the platform bus. The master devices find their slave iommus using the "iommus" field in their devicetree description. Since each slave iommu belongs to exactly one master, their is no additional data needed at probe to associate a slave with its master. An iommu device's power domain, clock and irq are all shared with its master device, and the master device must be careful to attach from the iommu only after powering and clocking it (and leave it powered and clocked before detaching). Because their is no guarantee what the status of the iommu is at probe, and since the driver does not even know if the device is powered, we delay requesting its irq until the master device attaches, at which point we have a guarantee that the device is powered and clocked and we can reset it and disable its interrupt mask. An iommu_domain describes a virtual iova address space. Each iommu_domain has a corresponding page table that lists the mappings from iova to physical address. For the rk3288 iommu, the page table has two levels: The Level 1 "directory_table" has 1024 4-byte dte entries. Each dte points to a level 2 "page_table". Each level 2 page_table has 1024 4-byte pte entries. Each pte points to a 4 KiB page of memory. An iommu_domain is created when a dma_iommu_mapping is created via arm_iommu_create_mapping. Master devices can then attach themselves to this mapping (or attach the mapping to themselves?) by calling arm_iommu_attach_device(). This in turn instructs the iommu driver to write the page table's physical address into the slave iommu's "Directory Table Entry" (DTE) register. In fact multiple master devices, each with their own slave iommu device, can all attach to the same mapping. The iommus for these devices will share the same iommu_domain and therefore point to the same page table. Thus, the iommu domain maintains a list of iommu devices which are attached. This driver relies on the iommu core to ensure that all devices have detached before destroying a domain. v6: - add .add/remove_device() callbacks. - parse platform_device device tree nodes for "iommus" property - store platform device pointer as group iommudata - Check for existence of iommu group instead of relying on a dev_get_drvdata() to return NULL for a NULL device. v7: - fixup some strings. - In rk_iommu_disable_paging() # and % were reversed. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Simon Xue <xxm@rock-chips.com> Reviewed-by: Grant Grundler <grundler@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-11-03 09:53:27 +07:00
config ROCKCHIP_IOMMU
bool "Rockchip IOMMU Support"
iommu/rockchip: Allow to compile with COMPILE_TEST Add optional CONFIG_COMPILE_TEST to dependency list. Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-11-04 00:16:56 +07:00
depends on ARCH_ROCKCHIP || COMPILE_TEST
iommu/rockchip: rk3288 iommu driver The rk3288 has several iommus. Each iommu belongs to a single master device. There is one device (ISP) that has two slave iommus, but that case is not yet supported by this driver. At subsys init, the iommu driver registers itself as the iommu driver for the platform bus. The master devices find their slave iommus using the "iommus" field in their devicetree description. Since each slave iommu belongs to exactly one master, their is no additional data needed at probe to associate a slave with its master. An iommu device's power domain, clock and irq are all shared with its master device, and the master device must be careful to attach from the iommu only after powering and clocking it (and leave it powered and clocked before detaching). Because their is no guarantee what the status of the iommu is at probe, and since the driver does not even know if the device is powered, we delay requesting its irq until the master device attaches, at which point we have a guarantee that the device is powered and clocked and we can reset it and disable its interrupt mask. An iommu_domain describes a virtual iova address space. Each iommu_domain has a corresponding page table that lists the mappings from iova to physical address. For the rk3288 iommu, the page table has two levels: The Level 1 "directory_table" has 1024 4-byte dte entries. Each dte points to a level 2 "page_table". Each level 2 page_table has 1024 4-byte pte entries. Each pte points to a 4 KiB page of memory. An iommu_domain is created when a dma_iommu_mapping is created via arm_iommu_create_mapping. Master devices can then attach themselves to this mapping (or attach the mapping to themselves?) by calling arm_iommu_attach_device(). This in turn instructs the iommu driver to write the page table's physical address into the slave iommu's "Directory Table Entry" (DTE) register. In fact multiple master devices, each with their own slave iommu device, can all attach to the same mapping. The iommus for these devices will share the same iommu_domain and therefore point to the same page table. Thus, the iommu domain maintains a list of iommu devices which are attached. This driver relies on the iommu core to ensure that all devices have detached before destroying a domain. v6: - add .add/remove_device() callbacks. - parse platform_device device tree nodes for "iommus" property - store platform device pointer as group iommudata - Check for existence of iommu group instead of relying on a dev_get_drvdata() to return NULL for a NULL device. v7: - fixup some strings. - In rk_iommu_disable_paging() # and % were reversed. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Simon Xue <xxm@rock-chips.com> Reviewed-by: Grant Grundler <grundler@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-11-03 09:53:27 +07:00
select IOMMU_API
select ARM_DMA_USE_IOMMU
help
Support for IOMMUs found on Rockchip rk32xx SOCs.
These IOMMUs allow virtualization of the address space used by most
cores within the multimedia subsystem.
Say Y here if you are using a Rockchip SoC that includes an IOMMU
device.
omap: iommu/iovmm: move to dedicated iommu folder Move OMAP's iommu drivers to the dedicated iommu drivers folder. While OMAP's iovmm (virtual memory manager) driver does not strictly belong to the iommu drivers folder, move it there as well, because it's by no means OMAP-specific (in concept. technically it is still coupled with OMAP's iommu). Eventually, iovmm will be completely replaced with the generic, iommu-based, dma-mapping API. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-08-16 03:21:41 +07:00
iommu: Add Allwinner H6 IOMMU driver The Allwinner H6 has introduced an IOMMU for a few DMA controllers, mostly video related: the display engine, the video decoders / encoders, the camera capture controller, etc. The design is pretty simple compared to other IOMMUs found in SoCs: there's a single instance, controlling all the masters, with a single address space. It also features a performance monitoring unit that allows to retrieve various informations (per-master and global TLB accesses, hits and misses, access latency, etc) that isn't supported at the moment. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/d122a8670361e36fc26b4ce2674a2223d30dc4cc.1589378833.git-series.maxime@cerno.tech Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-05-13 21:07:22 +07:00
config SUN50I_IOMMU
bool "Allwinner H6 IOMMU Support"
iommu: SUN50I_IOMMU should depend on HAS_DMA If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config): drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap': dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgprot' IOMMU_DMA must not be selected, unless HAS_DMA=y. Hence fix this by making SUN50I_IOMMU depend on HAS_DMA. Fixes: 4100b8c229b32835 ("iommu: Add Allwinner H6 IOMMU driver") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20200629121146.24011-1-geert@linux-m68k.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-06-29 19:11:46 +07:00
depends on HAS_DMA
iommu: Add Allwinner H6 IOMMU driver The Allwinner H6 has introduced an IOMMU for a few DMA controllers, mostly video related: the display engine, the video decoders / encoders, the camera capture controller, etc. The design is pretty simple compared to other IOMMUs found in SoCs: there's a single instance, controlling all the masters, with a single address space. It also features a performance monitoring unit that allows to retrieve various informations (per-master and global TLB accesses, hits and misses, access latency, etc) that isn't supported at the moment. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/d122a8670361e36fc26b4ce2674a2223d30dc4cc.1589378833.git-series.maxime@cerno.tech Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-05-13 21:07:22 +07:00
depends on ARCH_SUNXI || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
help
Support for the IOMMU introduced in the Allwinner H6 SoCs.
ARM: IOMMU: Tegra20: Add iommu_ops for GART driver Tegra 20 IOMMU H/W, GART (Graphics Address Relocation Table). This patch implements struct iommu_ops for GART for the upper IOMMU API. This H/W module supports only single virtual address space(domain), and manages a single level 1-to-1 mapping H/W translation page table. [With small fixes by Joerg Roedel] Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-16 22:36:37 +07:00
config TEGRA_IOMMU_GART
bool "Tegra GART IOMMU Support"
depends on ARCH_TEGRA_2x_SOC
iommu/tegra: gart: Integrate with Memory Controller driver The device-tree binding has been changed. There is no separate GART device anymore, it is squashed into the Memory Controller. Integrate GART module with the MC in a way it is done for the SMMU on Tegra30+. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-13 03:38:56 +07:00
depends on TEGRA_MC
ARM: IOMMU: Tegra20: Add iommu_ops for GART driver Tegra 20 IOMMU H/W, GART (Graphics Address Relocation Table). This patch implements struct iommu_ops for GART for the upper IOMMU API. This H/W module supports only single virtual address space(domain), and manages a single level 1-to-1 mapping H/W translation page table. [With small fixes by Joerg Roedel] Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-16 22:36:37 +07:00
select IOMMU_API
help
Enables support for remapping discontiguous physical memory
shared with the operating system into contiguous I/O virtual
space through the GART (Graphics Address Relocation Table)
hardware included on Tegra SoCs.
ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit). This patch implements struct iommu_ops for SMMU for the upper IOMMU API. This H/W module supports multiple virtual address spaces(domain x4), and manages 2 level H/W translation pagetable. Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-17 12:31:31 +07:00
config TEGRA_IOMMU_SMMU
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 14:24:44 +07:00
bool "NVIDIA Tegra SMMU Support"
depends on ARCH_TEGRA
depends on TEGRA_AHB
depends on TEGRA_MC
ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit). This patch implements struct iommu_ops for SMMU for the upper IOMMU API. This H/W module supports multiple virtual address spaces(domain x4), and manages 2 level H/W translation pagetable. Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-17 12:31:31 +07:00
select IOMMU_API
help
memory: Add NVIDIA Tegra memory controller support The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-16 14:24:44 +07:00
This driver supports the IOMMU hardware (SMMU) found on NVIDIA Tegra
memory: tegra: Add Tegra210 support Add the table of memory clients and SWGROUPs for Tegra210 to enable SMMU support for this new SoC. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-03-23 16:45:12 +07:00
SoCs (Tegra30 up to Tegra210).
ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit). This patch implements struct iommu_ops for SMMU for the upper IOMMU API. This H/W module supports multiple virtual address spaces(domain x4), and manages 2 level H/W translation pagetable. Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-17 12:31:31 +07:00
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
config EXYNOS_IOMMU
bool "Exynos IOMMU Support"
iommu: Tidy up Kconfig for SoC IOMMUs Wacky COMPILE_TEST dependencies based on who used to define dev_archdata.iommu can go. Dependencies on ARM or ARM64 already implied by the ARCH_* platform selection can go. The entire IOMMU_SUPPORT menu already depends on MMU, so those can go. IOMMU_DMA is for the architecture's DMA API implementation to choose, and its interface to IOMMU drivers is properly stubbed out if disabled, so dependencies on or selections of that can go (AMD_IOMMU is the current exception since the x86 drivers have to provide their own entire dma_map_ops implementation). Since commit ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA"), drivers which simply use the dma-mapping API should not need to depend on HAS_DMA, so those can go. And a long-dead option for code removed from the MSM driver 4 years ago can also go. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/7fb9c74dc6bd12a4619ca44c92408e91352f1be0.1593791968.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-03 23:03:19 +07:00
depends on ARCH_EXYNOS || COMPILE_TEST
iommu/exynos: prevent building on big-endian kernels Since we print the correct warning, an allmodconfig build is no longer clean but always prints it, which defeats compile-testing: drivers/iommu/exynos-iommu.c:58:2: error: #warning "revisit driver if we can enable big-endian ptes" [-Werror=cpp] This replaces the #warning with a dependency, moving warning text into a comment. Fixes: 1f59adb1766d ("iommu/exynos: Replace non-existing big-endian Kconfig option") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-07-28 20:19:19 +07:00
depends on !CPU_BIG_ENDIAN # revisit driver if we can enable big-endian ptes
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
select IOMMU_API
iommu/exynos: Select ARM_DMA_USE_IOMMU For IOMMU to use on Exynos platforms, we need to enable ARM_DMA_USE_IOMMU. It would be better to select it by default when EXYNOS_IOMMU is enabled. Signed-off-by: Tushar Behera <tushar.b@samsung.com> Reviewed-by: Sachin Kamat <sachin.kamat@samsung.com> Reviewed-by: Cho KyongHo <pullip.cho@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-07-04 16:31:08 +07:00
select ARM_DMA_USE_IOMMU
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
help
iommu/exynos: Fix trivial typo Fix typo and add missing punctuation. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-05-22 11:20:55 +07:00
Support for the IOMMU (System MMU) of Samsung Exynos application
processor family. This enables H/W multimedia accelerators to see
non-linear physical memory chunks as linear memory in their
address space.
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
If unsure, say N here.
config EXYNOS_IOMMU_DEBUG
bool "Debugging log for Exynos IOMMU"
depends on EXYNOS_IOMMU
help
Select this to see the detailed log message that shows what
iommu/exynos: Fix trivial typo Fix typo and add missing punctuation. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-05-22 11:20:55 +07:00
happens in the IOMMU driver.
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
iommu/exynos: Fix trivial typo Fix typo and add missing punctuation. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-05-22 11:20:55 +07:00
Say N unless you need kernel log message for IOMMU debugging.
iommu/exynos: Add iommu driver for EXYNOS Platforms This is the System MMU driver and IOMMU API implementation for EXYNOS SoC platforms. EXYNOS platforms has more than 10 System MMUs dedicated for each multimedia accelerators. The System MMU driver is already in arc/arm/plat-s5p but it is moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers there. Any device driver in EXYNOS platforms that needs to control its System MMU must call platform_set_sysmmu() to inform System MMU driver who will control it. platform_set_sysmmu() is defined in <mach/sysmmu.h> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-05-12 03:56:09 +07:00
iommu: Add driver for Renesas VMSA-compatible IPMMU Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-04-02 17:47:37 +07:00
config IPMMU_VMSA
bool "Renesas VMSA-compatible IPMMU"
iommu: Add missing dependencies parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate the following Kconfig warning. warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64)) IOMMU_IO_PGTABLE_LPAE depends on (COMPILE_TEST && !GENERIC_ATOMIC64), so any configuration option selecting it needs to have the same dependencies. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-09-11 03:43:37 +07:00
depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64)
iommu: Add driver for Renesas VMSA-compatible IPMMU Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-04-02 17:47:37 +07:00
select IOMMU_API
iommu/ipmmu-vmsa: Use the ARM LPAE page table allocator Replace the custom page table allocation implementation with the standard allocator. The driver loses the ability to map 64kB chunkgs using the PTE contiguous hint, hence the removal of the SZ_64K page size from the IOMMU page sizes bitmap. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-01-20 23:30:04 +07:00
select IOMMU_IO_PGTABLE_LPAE
iommu: Add driver for Renesas VMSA-compatible IPMMU Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-04-02 17:47:37 +07:00
select ARM_DMA_USE_IOMMU
help
iommu/ipmmu-vmsa: Clarify supported platforms The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs, but also other R-Car Gen2 and R-Car Gen3 SoCs. Drop a superfluous "Renesas" while at it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-07-25 20:10:29 +07:00
Support for the Renesas VMSA-compatible IPMMU found in the R-Mobile
iommu/renesas: Update help description for IPMMU_VMSA config ipmmu-vmsa driver is also used on Renesas RZ/G{1,2} Soc's, update the same to reflect the help description for IPMMU_VMSA config. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200911101912.20701-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-09-11 17:19:12 +07:00
APE6, R-Car Gen{2,3} and RZ/G{1,2} SoCs.
iommu: Add driver for Renesas VMSA-compatible IPMMU Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-04-02 17:47:37 +07:00
If unsure, say N.
powerpc/vfio: Enable on PowerNV platform This initializes IOMMU groups based on the IOMMU configuration discovered during the PCI scan on POWERNV (POWER non virtualized) platform. The IOMMU groups are to be used later by the VFIO driver, which is used for PCI pass through. It also implements an API for mapping/unmapping pages for guest PCI drivers and providing DMA window properties. This API is going to be used later by QEMU-VFIO to handle h_put_tce hypercalls from the KVM guest. The iommu_put_tce_user_mode() does only a single page mapping as an API for adding many mappings at once is going to be added later. Although this driver has been tested only on the POWERNV platform, it should work on any platform which supports TCE tables. As h_put_tce hypercall is received by the host kernel and processed by the QEMU (what involves calling the host kernel again), performance is not the best - circa 220MB/s on 10Gb ethernet network. To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config option and configure VFIO as required. Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-21 10:33:09 +07:00
config SPAPR_TCE_IOMMU
bool "sPAPR TCE IOMMU Support"
iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config Although SPAPR_TCE_IOMMU itself can be compile tested on certain PowerPC configurations, its presence makes arch/powerpc/kvm/Makefile to select modules which do not build in such configuration. The arch/powerpc/kvm/ modules use kvm_arch.spapr_tce_tables which exists only with CONFIG_PPC_BOOK3S_64. However these modules are selected when COMPILE_TEST and SPAPR_TCE_IOMMU are chosen leading to build failures: In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20:0, from arch/powerpc/kvm/book3s_64_vio_hv.c:22: arch/powerpc/include/asm/book3s/64/pgtable.h:17:0: error: "_PAGE_EXEC" redefined [-Werror] #define _PAGE_EXEC 0x00001 /* execute permission */ In file included from arch/powerpc/include/asm/book3s/32/pgtable.h:8:0, from arch/powerpc/include/asm/book3s/pgtable.h:8, from arch/powerpc/include/asm/pgtable.h:18, from include/linux/mm.h:95, from arch/powerpc/include/asm/io.h:29, from include/linux/io.h:13, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/kvm_host.h:7, from arch/powerpc/kvm/book3s_64_vio_hv.c:12: arch/powerpc/include/asm/book3s/32/hash.h:29:0: note: this is the location of the previous definition #define _PAGE_EXEC 0x200 /* software: exec allowed */ Fixes: e93a1695d7fb ("iommu: Enable compile testing for some of drivers") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200414142630.21153-1-krzk@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-04-14 21:26:30 +07:00
depends on PPC_POWERNV || PPC_PSERIES
powerpc/vfio: Enable on PowerNV platform This initializes IOMMU groups based on the IOMMU configuration discovered during the PCI scan on POWERNV (POWER non virtualized) platform. The IOMMU groups are to be used later by the VFIO driver, which is used for PCI pass through. It also implements an API for mapping/unmapping pages for guest PCI drivers and providing DMA window properties. This API is going to be used later by QEMU-VFIO to handle h_put_tce hypercalls from the KVM guest. The iommu_put_tce_user_mode() does only a single page mapping as an API for adding many mappings at once is going to be added later. Although this driver has been tested only on the POWERNV platform, it should work on any platform which supports TCE tables. As h_put_tce hypercall is received by the host kernel and processed by the QEMU (what involves calling the host kernel again), performance is not the best - circa 220MB/s on 10Gb ethernet network. To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config option and configure VFIO as required. Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-05-21 10:33:09 +07:00
select IOMMU_API
help
Enables bits of IOMMU API required by VFIO. The iommu_ops
is not implemented as it is not necessary for VFIO.
iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices Version three of the ARM SMMU architecture introduces significant changes and improvements over previous versions of the specification, necessitating a new driver in the Linux kernel. The main change to the programming interface is that the majority of the configuration data has been moved from MMIO registers to in-memory data structures, with communication between the CPU and the SMMU being mediated via in-memory circular queues. This patch adds an initial driver for SMMUv3 to Linux. We currently support pinned stage-1 (DMA) and stage-2 (KVM VFIO) mappings using the generic IO-pgtable code. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-05-27 23:25:59 +07:00
# ARM IOMMU support
iommu/arm: Add support for ARM Ltd. System MMU architecture This patch adds support for SMMUs implementing the ARM System MMU architecture versions 1 or 2. Both arm and arm64 are supported, although the v7s descriptor format is not used. Cc: Rob Herring <robherring2@gmail.com> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com> Cc: Olav Haugan <ohaugan@codeaurora.org> Cc: Joerg Roedel <joro@8bytes.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-06-25 00:31:25 +07:00
config ARM_SMMU
iommu/arm-smmu: Allow building as a module By conditionally dropping support for the legacy binding and exporting the newly introduced 'arm_smmu_impl_init()' function we can allow the ARM SMMU driver to be built as a module. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-12-19 19:03:51 +07:00
tristate "ARM Ltd. System MMU (SMMU) Support"
iommu: Tidy up Kconfig for SoC IOMMUs Wacky COMPILE_TEST dependencies based on who used to define dev_archdata.iommu can go. Dependencies on ARM or ARM64 already implied by the ARCH_* platform selection can go. The entire IOMMU_SUPPORT menu already depends on MMU, so those can go. IOMMU_DMA is for the architecture's DMA API implementation to choose, and its interface to IOMMU drivers is properly stubbed out if disabled, so dependencies on or selections of that can go (AMD_IOMMU is the current exception since the x86 drivers have to provide their own entire dma_map_ops implementation). Since commit ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA"), drivers which simply use the dma-mapping API should not need to depend on HAS_DMA, so those can go. And a long-dead option for code removed from the MSM driver 4 years ago can also go. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/7fb9c74dc6bd12a4619ca44c92408e91352f1be0.1593791968.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-03 23:03:19 +07:00
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
iommu/arm: Add support for ARM Ltd. System MMU architecture This patch adds support for SMMUs implementing the ARM System MMU architecture versions 1 or 2. Both arm and arm64 are supported, although the v7s descriptor format is not used. Cc: Rob Herring <robherring2@gmail.com> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com> Cc: Olav Haugan <ohaugan@codeaurora.org> Cc: Joerg Roedel <joro@8bytes.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-06-25 00:31:25 +07:00
select IOMMU_API
iommu/arm-smmu: make use of generic LPAE allocator The ARM SMMU can walk LPAE page tables, so make use of the generic allocator. Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:17:54 +07:00
select IOMMU_IO_PGTABLE_LPAE
iommu/arm: Add support for ARM Ltd. System MMU architecture This patch adds support for SMMUs implementing the ARM System MMU architecture versions 1 or 2. Both arm and arm64 are supported, although the v7s descriptor format is not used. Cc: Rob Herring <robherring2@gmail.com> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com> Cc: Olav Haugan <ohaugan@codeaurora.org> Cc: Joerg Roedel <joro@8bytes.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-06-25 00:31:25 +07:00
select ARM_DMA_USE_IOMMU if ARM
help
Support for implementations of the ARM System MMU architecture
iommu/arm-smmu: make use of generic LPAE allocator The ARM SMMU can walk LPAE page tables, so make use of the generic allocator. Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-15 00:17:54 +07:00
versions 1 and 2.
iommu/arm: Add support for ARM Ltd. System MMU architecture This patch adds support for SMMUs implementing the ARM System MMU architecture versions 1 or 2. Both arm and arm64 are supported, although the v7s descriptor format is not used. Cc: Rob Herring <robherring2@gmail.com> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com> Cc: Olav Haugan <ohaugan@codeaurora.org> Cc: Joerg Roedel <joro@8bytes.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-06-25 00:31:25 +07:00
Say Y here if your SoC includes an IOMMU device implementing
the ARM SMMU architecture.
iommu/arm-smmu: Allow building as a module By conditionally dropping support for the legacy binding and exporting the newly introduced 'arm_smmu_impl_init()' function we can allow the ARM SMMU driver to be built as a module. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-12-19 19:03:51 +07:00
config ARM_SMMU_LEGACY_DT_BINDINGS
bool "Support the legacy \"mmu-masters\" devicetree bindings"
depends on ARM_SMMU=y && OF
help
Support for the badly designed and deprecated "mmu-masters"
devicetree bindings. This allows some DMA masters to attach
to the SMMU but does not provide any support via the DMA API.
If you're lucky, you might be able to get VFIO up and running.
If you say Y here then you'll make me very sad. Instead, say N
and move your firmware to the utopian future that was 2016.
iommu/arm-smmu: Break insecure users by disabling bypass by default If you're bisecting why your peripherals stopped working, it's probably this CL. Specifically if you see this in your dmesg: Unexpected global fault, this could be serious ...then it's almost certainly this CL. Running your IOMMU-enabled peripherals with the IOMMU in bypass mode is insecure and effectively disables the protection they provide. There are few reasons to allow unmatched stream bypass, and even fewer good ones. This patch starts the transition over to make it much harder to run your system insecurely. Expected steps: 1. By default disable bypass (so anyone insecure will notice) but make it easy for someone to re-enable bypass with just a KConfig change. That's this patch. 2. After people have had a little time to come to grips with the fact that they need to set their IOMMUs properly and have had time to dig into how to do this, the KConfig will be eliminated and bypass will simply be disabled. Folks who are truly upset and still haven't fixed their system can either figure out how to add 'arm-smmu.disable_bypass=n' to their command line or revert the patch in their own private kernel. Of course these folks will be less secure. Suggested-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-03-02 02:20:17 +07:00
config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
bool "Default to disabling bypass on ARM SMMU v1 and v2"
depends on ARM_SMMU
default y
help
Say Y here to (by default) disable bypass streams such that
incoming transactions from devices that are not attached to
an iommu domain will report an abort back to the device and
will not be allowed to pass through the SMMU.
Any old kernels that existed before this KConfig was
introduced would default to _allowing_ bypass (AKA the
equivalent of NO for this config). However the default for
this option is YES because the old behavior is insecure.
There are few reasons to allow unmatched stream bypass, and
even fewer good ones. If saying YES here breaks your board
you should work on fixing your board. This KConfig option
is expected to be removed in the future and we'll simply
hardcode the bypass disable in the code.
NOTE: the kernel command line parameter
'arm-smmu.disable_bypass' will continue to override this
config.
iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices Version three of the ARM SMMU architecture introduces significant changes and improvements over previous versions of the specification, necessitating a new driver in the Linux kernel. The main change to the programming interface is that the majority of the configuration data has been moved from MMIO registers to in-memory data structures, with communication between the CPU and the SMMU being mediated via in-memory circular queues. This patch adds an initial driver for SMMUv3 to Linux. We currently support pinned stage-1 (DMA) and stage-2 (KVM VFIO) mappings using the generic IO-pgtable code. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-05-27 23:25:59 +07:00
config ARM_SMMU_V3
iommu/arm-smmu-v3: Allow building as a module By removing the redundant call to 'pci_request_acs()' we can allow the ARM SMMUv3 driver to be built as a module. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-12-19 19:03:49 +07:00
tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
iommu/arm-smmu: Support non-PCI devices with SMMUv3 With the device <-> stream ID relationship suitably abstracted and of_xlate() hooked up, the PCI dependency now looks, and is, entirely arbitrary. Any bus using the of_dma_configure() mechanism will work, so extend support to the platform and AMBA buses which do just that. Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-09-12 23:13:46 +07:00
depends on ARM64
iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices Version three of the ARM SMMU architecture introduces significant changes and improvements over previous versions of the specification, necessitating a new driver in the Linux kernel. The main change to the programming interface is that the majority of the configuration data has been moved from MMIO registers to in-memory data structures, with communication between the CPU and the SMMU being mediated via in-memory circular queues. This patch adds an initial driver for SMMUv3 to Linux. We currently support pinned stage-1 (DMA) and stage-2 (KVM VFIO) mappings using the generic IO-pgtable code. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-05-27 23:25:59 +07:00
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
iommu/arm-smmu: Add support for MSI on SMMUv3 Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> [will: tidied up the binding example and reworked most of the code] Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-10-14 00:32:30 +07:00
select GENERIC_MSI_IRQ_DOMAIN
iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices Version three of the ARM SMMU architecture introduces significant changes and improvements over previous versions of the specification, necessitating a new driver in the Linux kernel. The main change to the programming interface is that the majority of the configuration data has been moved from MMIO registers to in-memory data structures, with communication between the CPU and the SMMU being mediated via in-memory circular queues. This patch adds an initial driver for SMMUv3 to Linux. We currently support pinned stage-1 (DMA) and stage-2 (KVM VFIO) mappings using the generic IO-pgtable code. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-05-27 23:25:59 +07:00
help
Support for implementations of the ARM System MMU architecture
version 3 providing translation support to a PCIe root complex.
Say Y here if your system includes an IOMMU device implementing
the ARM SMMUv3 architecture.
iommu/arm-smmu-v3: Share process page tables With Shared Virtual Addressing (SVA), we need to mirror CPU TTBR, TCR, MAIR and ASIDs in SMMU contexts. Each SMMU has a single ASID space split into two sets, shared and private. Shared ASIDs correspond to those obtained from the arch ASID allocator, and private ASIDs are used for "classic" map/unmap DMA. A possible conflict happens when trying to use a shared ASID that has already been allocated for private use by the SMMU driver. This will be addressed in a later patch by replacing the private ASID. At the moment we return -EBUSY. Each mm_struct shared with the SMMU will have a single context descriptor. Add a refcount to keep track of this. It will be protected by the global SVA lock. Introduce a new arm-smmu-v3-sva.c file and the CONFIG_ARM_SMMU_V3_SVA option to let users opt in SVA support. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200918101852.582559-9-jean-philippe@linaro.org Signed-off-by: Will Deacon <will@kernel.org>
2020-09-18 17:18:48 +07:00
config ARM_SMMU_V3_SVA
bool "Shared Virtual Addressing support for the ARM SMMUv3"
depends on ARM_SMMU_V3
help
Support for sharing process address spaces with devices using the
SMMUv3.
Say Y here if your system supports SVA extensions such as PCIe PASID
and PRI.
iommu/s390: Add iommu api for s390 pci devices This adds an IOMMU API implementation for s390 PCI devices. Reviewed-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-08-27 20:33:03 +07:00
config S390_IOMMU
def_bool y if S390 && PCI
depends on S390 && PCI
select IOMMU_API
help
Support for the IOMMU API for s390 PCI devices.
vfio: ccw: basic implementation for vfio_ccw driver To make vfio support subchannel devices, we need a css driver for the vfio subchannels. This patch adds a basic vfio-ccw subchannel driver for this purpose. To enable VFIO for vfio-ccw, enable S390_CCW_IOMMU config option and configure VFIO as required. Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170317031743.40128-5-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-03-17 10:17:31 +07:00
config S390_CCW_IOMMU
bool "S390 CCW IOMMU Support"
iommu: Enable compile testing for some of drivers Some of the IOMMU drivers can be compile tested to increase build coverage. The OMAP, Rockchip and Exynos drivers use device.dev_archdata.iommu field which does not exist on all platforms. The sPAPR TCE and ARM SMMU have also restrictions where they can be built. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-03-04 03:27:51 +07:00
depends on S390 && CCW || COMPILE_TEST
vfio: ccw: basic implementation for vfio_ccw driver To make vfio support subchannel devices, we need a css driver for the vfio subchannels. This patch adds a basic vfio-ccw subchannel driver for this purpose. To enable VFIO for vfio-ccw, enable S390_CCW_IOMMU config option and configure VFIO as required. Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170317031743.40128-5-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-03-17 10:17:31 +07:00
select IOMMU_API
help
Enables bits of IOMMU API required by VFIO. The iommu_ops
is not implemented as it is not necessary for VFIO.
s390: vfio-ap: base implementation of VFIO AP device driver Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the interfaces to reserve AP devices for exclusive use by KVM guests. This is accomplished by unbinding the devices to be reserved for guest usage from the zcrypt device driver and binding them to the VFIO AP device driver. 2. Implements the functions, callbacks and sysfs attribute interfaces required to create one or more VFIO mediated devices each of which will be used to configure the AP matrix for a guest and serve as a file descriptor for facilitating communication between QEMU and the VFIO AP device driver. When the VFIO AP device driver is initialized: * It registers with the AP bus for control of type 10 (CEX4 and newer) AP queue devices. This limitation was imposed due to: 1. A desire to keep the code as simple as possible; 2. Some older models are no longer supported by the kernel and others are getting close to end of service. 3. A lack of older systems on which to test older devices. The probe and remove callbacks will be provided to support the binding/unbinding of AP queue devices to/from the VFIO AP device driver. * Creates a matrix device, /sys/devices/vfio_ap/matrix, to serve as the parent of the mediated devices created, one for each guest, and to hold the APQNs of the AP devices bound to the VFIO AP device driver. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Farhan Ali <alifm@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20180925231641.4954-5-akrowiak@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2018-09-26 06:16:19 +07:00
config S390_AP_IOMMU
bool "S390 AP IOMMU Support"
iommu: Enable compile testing for some of drivers Some of the IOMMU drivers can be compile tested to increase build coverage. The OMAP, Rockchip and Exynos drivers use device.dev_archdata.iommu field which does not exist on all platforms. The sPAPR TCE and ARM SMMU have also restrictions where they can be built. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-03-04 03:27:51 +07:00
depends on S390 && ZCRYPT || COMPILE_TEST
s390: vfio-ap: base implementation of VFIO AP device driver Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the interfaces to reserve AP devices for exclusive use by KVM guests. This is accomplished by unbinding the devices to be reserved for guest usage from the zcrypt device driver and binding them to the VFIO AP device driver. 2. Implements the functions, callbacks and sysfs attribute interfaces required to create one or more VFIO mediated devices each of which will be used to configure the AP matrix for a guest and serve as a file descriptor for facilitating communication between QEMU and the VFIO AP device driver. When the VFIO AP device driver is initialized: * It registers with the AP bus for control of type 10 (CEX4 and newer) AP queue devices. This limitation was imposed due to: 1. A desire to keep the code as simple as possible; 2. Some older models are no longer supported by the kernel and others are getting close to end of service. 3. A lack of older systems on which to test older devices. The probe and remove callbacks will be provided to support the binding/unbinding of AP queue devices to/from the VFIO AP device driver. * Creates a matrix device, /sys/devices/vfio_ap/matrix, to serve as the parent of the mediated devices created, one for each guest, and to hold the APQNs of the AP devices bound to the VFIO AP device driver. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Farhan Ali <alifm@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20180925231641.4954-5-akrowiak@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2018-09-26 06:16:19 +07:00
select IOMMU_API
help
Enables bits of IOMMU API required by VFIO. The iommu_ops
is not implemented as it is not necessary for VFIO.
iommu/mediatek: Add mt8173 IOMMU driver 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-23 00:20:50 +07:00
config MTK_IOMMU
bool "MTK IOMMU Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
iommu/mediatek: Select ARM_DMA_USE_IOMMU 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-29 16:19:06 +07:00
select ARM_DMA_USE_IOMMU
iommu/mediatek: Add mt8173 IOMMU driver 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-23 00:20:50 +07:00
select IOMMU_API
select IOMMU_IO_PGTABLE_ARMV7S
select MEMORY
select MTK_SMI
help
Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
Memory Management Unit. This option enables remapping of DMA memory
accesses for the multimedia subsystem.
If unsure, say N here.
iommu/mediatek: add support for mtk iommu generation one HW Mediatek SoC's M4U has two generations of HW architcture. Generation one uses flat, one layer pagetable, and was shipped with ARM architecture, it only supports 4K size page mapping. MT2701 SoC uses this generation one m4u HW. Generation two uses the ARM short-descriptor translation table format for address translation, and was shipped with ARM64 architecture, MT8173 uses this generation two m4u HW. All the two generation iommu HW only have one iommu domain, and all its iommu clients share the same iova address. These two generation m4u HW have slit different register groups and register offset, but most register names are the same. This patch add iommu support for mediatek SoC mt2701. Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2016-06-08 16:51:00 +07:00
config MTK_IOMMU_V1
bool "MTK IOMMU Version 1 (M4U gen1) Support"
depends on ARM
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
select MEMORY
select MTK_SMI
help
Support for the M4U on certain Mediatek SoCs. M4U generation 1 HW is
Multimedia Memory Managememt Unit. This option enables remapping of
DMA memory accesses for the multimedia subsystem.
if unsure, say N here.
iommu/qcom: Add qcom_iommu An iommu driver for Qualcomm "B" family devices which do implement the ARM SMMU spec, but not in a way that is compatible with how the arm-smmu driver is designed. It seems SMMU_SCR1.GASRAE=1 so the global register space is not accessible. This means it needs to get configuration from devicetree instead of setting it up dynamically. In the end, other than register definitions, there is not much code to share with arm-smmu (other than what has already been refactored out into the pgtable helpers). Signed-off-by: Rob Clark <robdclark@gmail.com> Tested-by: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-08-09 21:43:04 +07:00
config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
iommu: Add missing dependencies parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate the following Kconfig warning. warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64)) IOMMU_IO_PGTABLE_LPAE depends on (COMPILE_TEST && !GENERIC_ATOMIC64), so any configuration option selecting it needs to have the same dependencies. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-09-11 03:43:37 +07:00
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
iommu/qcom: Add qcom_iommu An iommu driver for Qualcomm "B" family devices which do implement the ARM SMMU spec, but not in a way that is compatible with how the arm-smmu driver is designed. It seems SMMU_SCR1.GASRAE=1 so the global register space is not accessible. This means it needs to get configuration from devicetree instead of setting it up dynamically. In the end, other than register definitions, there is not much code to share with arm-smmu (other than what has already been refactored out into the pgtable helpers). Signed-off-by: Rob Clark <robdclark@gmail.com> Tested-by: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-08-09 21:43:04 +07:00
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
help
Support for IOMMU on certain Qualcomm SoCs.
iommu/hyper-v: Add Hyper-V stub IOMMU driver On the bare metal, enabling X2APIC mode requires interrupt remapping function which helps to deliver irq to cpu with 32-bit APIC ID. Hyper-V doesn't provide interrupt remapping function so far and Hyper-V MSI protocol already supports to deliver interrupt to the CPU whose virtual processor index is more than 255. IO-APIC interrupt still has 8-bit APIC ID limitation. This patch is to add Hyper-V stub IOMMU driver in order to enable X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC interrupt remapping capability when X2APIC mode is available. Otherwise, it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID. Define 24 IO-APIC remapping entries because Hyper-V only expose one single IO-APIC and one IO-APIC has 24 pins according IO-APIC spec( https://pdos.csail.mit.edu/6.828/2016/readings/ia32/ioapic.pdf). Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-02-27 21:54:04 +07:00
config HYPERV_IOMMU
bool "Hyper-V x2APIC IRQ Handling"
drivers: iommu: hyperv: Make HYPERV_IOMMU only available on x86 Currently hyperv-iommu is implemented in a x86 specific way, for example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86 as a preparation for enabling HyperV on architecture other than x86. Cc: Lan Tianyu <Tianyu.Lan@microsoft.com> Cc: Michael Kelley <mikelley@microsoft.com> Cc: linux-hyperv@vger.kernel.org Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-17 07:57:03 +07:00
depends on HYPERV && X86
iommu/hyper-v: Add Hyper-V stub IOMMU driver On the bare metal, enabling X2APIC mode requires interrupt remapping function which helps to deliver irq to cpu with 32-bit APIC ID. Hyper-V doesn't provide interrupt remapping function so far and Hyper-V MSI protocol already supports to deliver interrupt to the CPU whose virtual processor index is more than 255. IO-APIC interrupt still has 8-bit APIC ID limitation. This patch is to add Hyper-V stub IOMMU driver in order to enable X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC interrupt remapping capability when X2APIC mode is available. Otherwise, it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID. Define 24 IO-APIC remapping entries because Hyper-V only expose one single IO-APIC and one IO-APIC has 24 pins according IO-APIC spec( https://pdos.csail.mit.edu/6.828/2016/readings/ia32/ioapic.pdf). Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-02-27 21:54:04 +07:00
select IOMMU_API
default HYPERV
help
Stub IOMMU driver to handle IRQs as to allow Hyper-V Linux
guests to run with x2APIC mode enabled.
iommu: Add virtio-iommu driver The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code transforms calls coming from the IOMMU API into corresponding virtio requests. Mappings are kept in an interval tree instead of page tables. A little more work is required for modular and x86 support, so for the moment the driver depends on CONFIG_VIRTIO=y and CONFIG_ARM64. Tested-by: Bharat Bhushan <bharat.bhushan@nxp.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-15 19:19:57 +07:00
config VIRTIO_IOMMU
iommu/virtio: Build virtio-iommu as module Now that the infrastructure changes are in place, enable virtio-iommu to be built as a module. Remove the redundant pci_request_acs() call, since it's not exported but is already invoked during DMA setup. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-02-14 23:38:27 +07:00
tristate "Virtio IOMMU driver"
depends on VIRTIO
iommu: Add virtio-iommu driver The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code transforms calls coming from the IOMMU API into corresponding virtio requests. Mappings are kept in an interval tree instead of page tables. A little more work is required for modular and x86 support, so for the moment the driver depends on CONFIG_VIRTIO=y and CONFIG_ARM64. Tested-by: Bharat Bhushan <bharat.bhushan@nxp.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-15 19:19:57 +07:00
depends on ARM64
select IOMMU_API
select INTERVAL_TREE
help
Para-virtualised IOMMU driver with virtio.
Say Y here if you intend to run this kernel as a guest.
iommu: Move iommu Kconfig entries to submenu For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-06-14 20:51:54 +07:00
endif # IOMMU_SUPPORT
Reference in New Issue Copy Permalink