2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2019-01-03 05:16:57 +08:00
|
|
|
# The IOVA library may also be used by non-IOMMU_API users
|
|
|
|
|
config IOMMU_IOVA
|
|
|
|
|
tristate
|
|
|
|
|
|
2019-10-03 03:42:41 +08:00
|
|
|
# The IOASID library may also be used by non-IOMMU_API users
|
|
|
|
|
config IOASID
|
|
|
|
|
tristate
|
|
|
|
|
|
2011-06-02 07:48:05 +08:00
|
|
|
# IOMMU_API always gets selected by whoever wants it.
|
|
|
|
|
config IOMMU_API
|
|
|
|
|
bool
|
2011-06-02 08:20:08 +08:00
|
|
|
|
2011-06-14 21:51:54 +08:00
|
|
|
menuconfig IOMMU_SUPPORT
|
|
|
|
|
bool "IOMMU Hardware Support"
|
2015-01-28 22:45:53 +08:00
|
|
|
depends on MMU
|
2011-06-14 21:51:54 +08:00
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-06-14 21:51:54 +08: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
|
|
|
|
|
|
2014-11-15 01:16:49 +08:00
|
|
|
menu "Generic IOMMU Pagetable Support"
|
|
|
|
|
|
|
|
|
|
# Selected by the actual pagetable implementations
|
|
|
|
|
config IOMMU_IO_PGTABLE
|
|
|
|
|
bool
|
|
|
|
|
|
2014-11-15 01:18:23 +08:00
|
|
|
config IOMMU_IO_PGTABLE_LPAE
|
|
|
|
|
bool "ARMv7/v8 Long Descriptor Format"
|
|
|
|
|
select IOMMU_IO_PGTABLE
|
2018-04-18 01:49:09 +08:00
|
|
|
depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
2014-11-15 01:18:23 +08: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.
|
|
|
|
|
|
2014-11-18 07:31:12 +08: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.
|
|
|
|
|
|
2016-01-27 01:13:13 +08:00
|
|
|
config IOMMU_IO_PGTABLE_ARMV7S
|
|
|
|
|
bool "ARMv7/v8 Short Descriptor Format"
|
|
|
|
|
select IOMMU_IO_PGTABLE
|
2018-04-18 01:49:09 +08:00
|
|
|
depends on ARM || ARM64 || COMPILE_TEST
|
2016-01-27 01:13:13 +08: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.
|
|
|
|
|
|
2022-09-16 17:41:49 +08:00
|
|
|
config IOMMU_IO_PGTABLE_DART
|
|
|
|
|
bool "Apple DART Formats"
|
|
|
|
|
select IOMMU_IO_PGTABLE
|
|
|
|
|
depends on ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
|
|
|
|
help
|
|
|
|
|
Enable support for the Apple DART pagetable formats. These include
|
|
|
|
|
the t8020 and t6000/t8110 DART formats used in Apple M1/M2 family
|
|
|
|
|
SoCs.
|
|
|
|
|
|
|
|
|
|
If unsure, say N here.
|
|
|
|
|
|
2014-11-15 01:16:49 +08:00
|
|
|
endmenu
|
|
|
|
|
|
2018-06-13 05:41:21 +08: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.
|
|
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
choice
|
|
|
|
|
prompt "IOMMU default domain type"
|
2018-07-21 02:02:23 +08:00
|
|
|
depends on IOMMU_API
|
2021-09-08 20:55:37 +08:00
|
|
|
default IOMMU_DEFAULT_DMA_LAZY if X86 || IA64
|
2021-08-11 20:21:37 +08:00
|
|
|
default IOMMU_DEFAULT_DMA_STRICT
|
2019-11-21 11:19:30 +08:00
|
|
|
help
|
2021-08-11 20:21:37 +08:00
|
|
|
Choose the type of IOMMU domain used to manage DMA API usage by
|
|
|
|
|
device drivers. The options here typically represent different
|
|
|
|
|
levels of tradeoff between robustness/security and performance,
|
|
|
|
|
depending on the IOMMU driver. Not all IOMMUs support all options.
|
|
|
|
|
This choice can be overridden at boot via the command line, and for
|
|
|
|
|
some devices also at runtime via sysfs.
|
2018-07-21 02:02:23 +08:00
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
If unsure, keep the default.
|
2021-07-12 19:12:17 +08:00
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
config IOMMU_DEFAULT_DMA_STRICT
|
|
|
|
|
bool "Translated - Strict"
|
2021-07-12 19:12:17 +08:00
|
|
|
help
|
2021-08-11 20:21:37 +08:00
|
|
|
Trusted devices use translation to restrict their access to only
|
|
|
|
|
DMA-mapped pages, with strict TLB invalidation on unmap. Equivalent
|
|
|
|
|
to passing "iommu.passthrough=0 iommu.strict=1" on the command line.
|
2021-07-12 19:12:17 +08:00
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
Untrusted devices always use this mode, with an additional layer of
|
|
|
|
|
bounce-buffering such that they cannot gain access to any unrelated
|
|
|
|
|
data within a mapped page.
|
2021-07-12 19:12:17 +08:00
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
config IOMMU_DEFAULT_DMA_LAZY
|
|
|
|
|
bool "Translated - Lazy"
|
2021-07-12 19:12:17 +08:00
|
|
|
help
|
2021-08-11 20:21:37 +08:00
|
|
|
Trusted devices use translation to restrict their access to only
|
|
|
|
|
DMA-mapped pages, but with "lazy" batched TLB invalidation. This
|
|
|
|
|
mode allows higher performance with some IOMMUs due to reduced TLB
|
|
|
|
|
flushing, but at the cost of reduced isolation since devices may be
|
|
|
|
|
able to access memory for some time after it has been unmapped.
|
|
|
|
|
Equivalent to passing "iommu.passthrough=0 iommu.strict=0" on the
|
|
|
|
|
command line.
|
|
|
|
|
|
|
|
|
|
If this mode is not supported by the IOMMU driver, the effective
|
|
|
|
|
runtime default will fall back to IOMMU_DEFAULT_DMA_STRICT.
|
2021-07-12 19:12:17 +08:00
|
|
|
|
2021-08-11 20:21:37 +08:00
|
|
|
config IOMMU_DEFAULT_PASSTHROUGH
|
|
|
|
|
bool "Passthrough"
|
2021-07-12 19:12:17 +08:00
|
|
|
help
|
2021-08-11 20:21:37 +08:00
|
|
|
Trusted devices are identity-mapped, giving them unrestricted access
|
|
|
|
|
to memory with minimal performance overhead. Equivalent to passing
|
|
|
|
|
"iommu.passthrough=1" (historically "iommu=pt") on the command line.
|
|
|
|
|
|
|
|
|
|
If this mode is not supported by the IOMMU driver, the effective
|
|
|
|
|
runtime default will fall back to IOMMU_DEFAULT_DMA_STRICT.
|
2021-07-12 19:12:17 +08:00
|
|
|
|
|
|
|
|
endchoice
|
2018-07-21 02:02:23 +08:00
|
|
|
|
2012-06-25 19:23:54 +08:00
|
|
|
config OF_IOMMU
|
2019-11-21 11:19:30 +08:00
|
|
|
def_bool y
|
|
|
|
|
depends on OF && IOMMU_API
|
2012-06-25 19:23:54 +08:00
|
|
|
|
2015-10-02 03:13:58 +08:00
|
|
|
# IOMMU-agnostic DMA-mapping layer
|
|
|
|
|
config IOMMU_DMA
|
2022-08-17 01:28:03 +08:00
|
|
|
def_bool ARM64 || IA64 || X86
|
2020-07-08 15:30:00 +08:00
|
|
|
select DMA_OPS
|
2015-10-02 03:13:58 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select IOMMU_IOVA
|
2019-05-01 21:58:19 +08:00
|
|
|
select IRQ_MSI_IOMMU
|
2016-02-29 19:13:39 +08:00
|
|
|
select NEED_SG_DMA_LENGTH
|
2015-10-02 03:13:58 +08:00
|
|
|
|
2022-02-08 07:02:44 +08:00
|
|
|
# Shared Virtual Addressing
|
|
|
|
|
config IOMMU_SVA
|
2020-11-06 23:50:48 +08:00
|
|
|
bool
|
|
|
|
|
select IOASID
|
|
|
|
|
|
2013-07-15 12:50:57 +08:00
|
|
|
config FSL_PAMU
|
|
|
|
|
bool "Freescale IOMMU support"
|
2017-08-09 21:00:36 +08:00
|
|
|
depends on PCI
|
2017-08-09 21:04:47 +08:00
|
|
|
depends on PHYS_64BIT
|
2016-03-17 12:15:44 +08:00
|
|
|
depends on PPC_E500MC || (COMPILE_TEST && PPC)
|
2013-07-15 12:50:57 +08: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.
|
|
|
|
|
|
2011-06-02 08:20:08 +08:00
|
|
|
# MSM IOMMU support
|
|
|
|
|
config MSM_IOMMU
|
|
|
|
|
bool "MSM IOMMU Support"
|
2015-01-20 23:13:33 +08:00
|
|
|
depends on ARM
|
|
|
|
|
depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
|
2011-06-02 08:20:08 +08:00
|
|
|
select IOMMU_API
|
2016-06-13 19:36:06 +08:00
|
|
|
select IOMMU_IO_PGTABLE_ARMV7S
|
2011-06-02 08:20:08 +08: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.
|
|
|
|
|
|
2020-07-01 04:06:36 +08:00
|
|
|
source "drivers/iommu/amd/Kconfig"
|
2020-07-01 04:06:35 +08:00
|
|
|
source "drivers/iommu/intel/Kconfig"
|
2020-01-02 08:18:02 +08:00
|
|
|
|
2011-08-24 08:05:25 +08:00
|
|
|
config IRQ_REMAP
|
2013-01-17 10:53:39 +08:00
|
|
|
bool "Support for Interrupt Remapping"
|
|
|
|
|
depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
|
2011-08-24 08:05:25 +08:00
|
|
|
select DMAR_TABLE
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-06-11 02:42:27 +08: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.
|
2011-06-14 21:51:54 +08:00
|
|
|
|
2011-08-16 04:21:41 +08:00
|
|
|
# OMAP IOMMU support
|
|
|
|
|
config OMAP_IOMMU
|
|
|
|
|
bool "OMAP IOMMU Support"
|
2015-01-20 23:13:33 +08:00
|
|
|
depends on ARCH_OMAP2PLUS || COMPILE_TEST
|
2011-08-16 04:21:41 +08:00
|
|
|
select IOMMU_API
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2014-11-11 16:17:00 +08:00
|
|
|
The OMAP3 media platform drivers depend on iommu support,
|
|
|
|
|
if you need them say Y here.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
|
|
|
|
config OMAP_IOMMU_DEBUG
|
2014-10-23 06:22:30 +08:00
|
|
|
bool "Export OMAP IOMMU internals in DebugFS"
|
|
|
|
|
depends on OMAP_IOMMU && DEBUG_FS
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2014-10-23 06:22:30 +08:00
|
|
|
Select this to see extensive information about
|
|
|
|
|
the internal state of OMAP IOMMU in debugfs.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
2014-10-23 06:22:30 +08:00
|
|
|
Say N unless you know you need this.
|
2011-08-16 04:21:41 +08: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 10:53:27 +08:00
|
|
|
config ROCKCHIP_IOMMU
|
|
|
|
|
bool "Rockchip IOMMU Support"
|
2014-11-04 01:16:56 +08: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 10:53:27 +08: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.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
2020-05-13 22:07:22 +08:00
|
|
|
config SUN50I_IOMMU
|
|
|
|
|
bool "Allwinner H6 IOMMU Support"
|
2020-06-29 20:11:46 +08:00
|
|
|
depends on HAS_DMA
|
2020-05-13 22:07:22 +08: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.
|
|
|
|
|
|
2011-11-16 23:36:37 +08:00
|
|
|
config TEGRA_IOMMU_GART
|
|
|
|
|
bool "Tegra GART IOMMU Support"
|
|
|
|
|
depends on ARCH_TEGRA_2x_SOC
|
2018-12-13 04:38:56 +08:00
|
|
|
depends on TEGRA_MC
|
2011-11-16 23:36:37 +08: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.
|
|
|
|
|
|
2011-11-17 13:31:31 +08:00
|
|
|
config TEGRA_IOMMU_SMMU
|
2014-04-16 15:24:44 +08:00
|
|
|
bool "NVIDIA Tegra SMMU Support"
|
|
|
|
|
depends on ARCH_TEGRA
|
|
|
|
|
depends on TEGRA_AHB
|
|
|
|
|
depends on TEGRA_MC
|
2011-11-17 13:31:31 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
2014-04-16 15:24:44 +08:00
|
|
|
This driver supports the IOMMU hardware (SMMU) found on NVIDIA Tegra
|
2015-03-23 17:45:12 +08:00
|
|
|
SoCs (Tegra30 up to Tegra210).
|
2011-11-17 13:31:31 +08:00
|
|
|
|
2012-05-12 04:56:09 +08:00
|
|
|
config EXYNOS_IOMMU
|
|
|
|
|
bool "Exynos IOMMU Support"
|
2020-07-04 00:03:19 +08:00
|
|
|
depends on ARCH_EXYNOS || COMPILE_TEST
|
2017-07-28 21:19:19 +08:00
|
|
|
depends on !CPU_BIG_ENDIAN # revisit driver if we can enable big-endian ptes
|
2012-05-12 04:56:09 +08:00
|
|
|
select IOMMU_API
|
2014-07-04 17:31:08 +08:00
|
|
|
select ARM_DMA_USE_IOMMU
|
2012-05-12 04:56:09 +08:00
|
|
|
help
|
2014-05-22 12:20:55 +08: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.
|
2012-05-12 04:56:09 +08: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
|
2014-05-22 12:20:55 +08:00
|
|
|
happens in the IOMMU driver.
|
2012-05-12 04:56:09 +08:00
|
|
|
|
2014-05-22 12:20:55 +08:00
|
|
|
Say N unless you need kernel log message for IOMMU debugging.
|
2012-05-12 04:56:09 +08:00
|
|
|
|
2014-04-02 18:47:37 +08:00
|
|
|
config IPMMU_VMSA
|
|
|
|
|
bool "Renesas VMSA-compatible IPMMU"
|
2017-09-11 04:43:37 +08:00
|
|
|
depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
2014-04-02 18:47:37 +08:00
|
|
|
select IOMMU_API
|
2015-01-21 00:30:04 +08:00
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
2014-04-02 18:47:37 +08:00
|
|
|
select ARM_DMA_USE_IOMMU
|
|
|
|
|
help
|
2018-07-25 21:10:29 +08:00
|
|
|
Support for the Renesas VMSA-compatible IPMMU found in the R-Mobile
|
2020-09-11 18:19:12 +08:00
|
|
|
APE6, R-Car Gen{2,3} and RZ/G{1,2} SoCs.
|
2014-04-02 18:47:37 +08:00
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2013-05-21 11:33:09 +08: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 22:26:30 +08:00
|
|
|
depends on PPC_POWERNV || PPC_PSERIES
|
2013-05-21 11:33:09 +08: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.
|
|
|
|
|
|
2021-08-03 20:16:51 +08:00
|
|
|
config APPLE_DART
|
|
|
|
|
tristate "Apple DART IOMMU Support"
|
2021-08-10 21:47:19 +08:00
|
|
|
depends on ARCH_APPLE || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
2021-08-03 20:16:51 +08:00
|
|
|
select IOMMU_API
|
2022-09-16 17:41:49 +08:00
|
|
|
select IOMMU_IO_PGTABLE_DART
|
2021-08-03 20:16:51 +08:00
|
|
|
default ARCH_APPLE
|
|
|
|
|
help
|
|
|
|
|
Support for Apple DART (Device Address Resolution Table) IOMMUs
|
|
|
|
|
found in Apple ARM SoCs like the M1.
|
|
|
|
|
This IOMMU is required for most peripherals using DMA to access
|
|
|
|
|
the main memory.
|
|
|
|
|
|
|
|
|
|
Say Y here if you are using an Apple SoC.
|
|
|
|
|
|
2015-05-28 00:25:59 +08:00
|
|
|
# ARM IOMMU support
|
2013-06-25 01:31:25 +08:00
|
|
|
config ARM_SMMU
|
2019-12-19 20:03:51 +08:00
|
|
|
tristate "ARM Ltd. System MMU (SMMU) Support"
|
2020-07-04 00:03:19 +08:00
|
|
|
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
2013-06-25 01:31:25 +08:00
|
|
|
select IOMMU_API
|
2014-11-15 01:17:54 +08:00
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
2013-06-25 01:31:25 +08:00
|
|
|
select ARM_DMA_USE_IOMMU if ARM
|
|
|
|
|
help
|
|
|
|
|
Support for implementations of the ARM System MMU architecture
|
2014-11-15 01:17:54 +08:00
|
|
|
versions 1 and 2.
|
2013-06-25 01:31:25 +08:00
|
|
|
|
|
|
|
|
Say Y here if your SoC includes an IOMMU device implementing
|
|
|
|
|
the ARM SMMU architecture.
|
|
|
|
|
|
2019-12-19 20:03:51 +08: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.
|
|
|
|
|
|
2019-03-02 03:20:17 +08: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.
|
|
|
|
|
|
2021-10-11 01:27:03 +08:00
|
|
|
config ARM_SMMU_QCOM
|
|
|
|
|
def_tristate y
|
|
|
|
|
depends on ARM_SMMU && ARCH_QCOM
|
|
|
|
|
select QCOM_SCM
|
|
|
|
|
help
|
|
|
|
|
When running on a Qualcomm platform that has the custom variant
|
|
|
|
|
of the ARM SMMU, this needs to be built into the SMMU driver.
|
|
|
|
|
|
2022-07-08 17:42:30 +08:00
|
|
|
config ARM_SMMU_QCOM_DEBUG
|
|
|
|
|
bool "ARM SMMU QCOM implementation defined debug support"
|
|
|
|
|
depends on ARM_SMMU_QCOM
|
|
|
|
|
help
|
|
|
|
|
Support for implementation specific debug features in ARM SMMU
|
|
|
|
|
hardware found in QTI platforms.
|
|
|
|
|
|
|
|
|
|
Say Y here to enable debug for issues such as TLB sync timeouts
|
|
|
|
|
which requires implementation defined register dumps.
|
|
|
|
|
|
2015-05-28 00:25:59 +08:00
|
|
|
config ARM_SMMU_V3
|
2019-12-19 20:03:49 +08:00
|
|
|
tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
|
2016-09-13 00:13:46 +08:00
|
|
|
depends on ARM64
|
2015-05-28 00:25:59 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
2015-10-14 01:32:30 +08:00
|
|
|
select GENERIC_MSI_IRQ_DOMAIN
|
2015-05-28 00:25:59 +08: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.
|
|
|
|
|
|
2020-09-18 18:18:48 +08:00
|
|
|
config ARM_SMMU_V3_SVA
|
|
|
|
|
bool "Shared Virtual Addressing support for the ARM SMMUv3"
|
|
|
|
|
depends on ARM_SMMU_V3
|
2022-02-08 07:02:44 +08:00
|
|
|
select IOMMU_SVA
|
iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()
The sva_bind() function allows devices to access process address spaces
using a PASID (aka SSID).
(1) bind() allocates or gets an existing MMU notifier tied to the
(domain, mm) pair. Each mm gets one PASID.
(2) Any change to the address space calls invalidate_range() which sends
ATC invalidations (in a subsequent patch).
(3) When the process address space dies, the release() notifier disables
the CD to allow reclaiming the page tables. Since release() has to
be light we do not instruct device drivers to stop DMA here, we just
ignore incoming page faults from this point onwards.
To avoid any event 0x0a print (C_BAD_CD) we disable translation
without clearing CD.V. PCIe Translation Requests and Page Requests
are silently denied. Don't clear the R bit because the S bit can't
be cleared when STALL_MODEL==0b10 (forced), and clearing R without
clearing S is useless. Faulting transactions will stall and will be
aborted by the IOPF handler.
(4) After stopping DMA, the device driver releases the bond by calling
unbind(). We release the MMU notifier, free the PASID and the bond.
Three structures keep track of bonds:
* arm_smmu_bond: one per {device, mm} pair, the handle returned to the
device driver for a bind() request.
* arm_smmu_mmu_notifier: one per {domain, mm} pair, deals with ATS/TLB
invalidations and clearing the context descriptor on mm exit.
* arm_smmu_ctx_desc: one per mm, holds the pinned ASID and pgd.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20201106155048.997886-4-jean-philippe@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
2020-11-06 23:50:49 +08:00
|
|
|
select MMU_NOTIFIER
|
2020-09-18 18:18:48 +08:00
|
|
|
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.
|
|
|
|
|
|
2015-08-27 21:33:03 +08: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.
|
|
|
|
|
|
2017-03-17 11:17:31 +08:00
|
|
|
config S390_CCW_IOMMU
|
|
|
|
|
bool "S390 CCW IOMMU Support"
|
2020-03-04 04:27:51 +08:00
|
|
|
depends on S390 && CCW || COMPILE_TEST
|
2017-03-17 11:17:31 +08: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.
|
|
|
|
|
|
2018-09-26 07:16:19 +08:00
|
|
|
config S390_AP_IOMMU
|
|
|
|
|
bool "S390 AP IOMMU Support"
|
2020-03-04 04:27:51 +08:00
|
|
|
depends on S390 && ZCRYPT || COMPILE_TEST
|
2018-09-26 07:16:19 +08: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.
|
|
|
|
|
|
2016-02-23 01:20:50 +08:00
|
|
|
config MTK_IOMMU
|
2021-03-26 11:23:37 +08:00
|
|
|
tristate "MediaTek IOMMU Support"
|
2016-02-23 01:20:50 +08:00
|
|
|
depends on ARCH_MEDIATEK || COMPILE_TEST
|
2016-02-29 17:19:06 +08:00
|
|
|
select ARM_DMA_USE_IOMMU
|
2016-02-23 01:20:50 +08: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.
|
|
|
|
|
|
2016-06-08 17:51:00 +08:00
|
|
|
config MTK_IOMMU_V1
|
2021-03-26 11:23:36 +08:00
|
|
|
tristate "MediaTek IOMMU Version 1 (M4U gen1) Support"
|
2016-06-08 17:51:00 +08:00
|
|
|
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.
|
|
|
|
|
|
2017-08-09 22:43:04 +08:00
|
|
|
config QCOM_IOMMU
|
|
|
|
|
# Note: iommu drivers cannot (yet?) be built as modules
|
|
|
|
|
bool "Qualcomm IOMMU Support"
|
2017-09-11 04:43:37 +08:00
|
|
|
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
|
2021-09-28 15:50:27 +08:00
|
|
|
select QCOM_SCM
|
2017-08-09 22:43:04 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
|
|
|
|
select ARM_DMA_USE_IOMMU
|
|
|
|
|
help
|
|
|
|
|
Support for IOMMU on certain Qualcomm SoCs.
|
|
|
|
|
|
2019-02-27 22:54:04 +08:00
|
|
|
config HYPERV_IOMMU
|
|
|
|
|
bool "Hyper-V x2APIC IRQ Handling"
|
2019-10-17 08:57:03 +08:00
|
|
|
depends on HYPERV && X86
|
2019-02-27 22:54:04 +08: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.
|
|
|
|
|
|
2019-01-15 20:19:57 +08:00
|
|
|
config VIRTIO_IOMMU
|
2020-02-15 00:38:27 +08:00
|
|
|
tristate "Virtio IOMMU driver"
|
|
|
|
|
depends on VIRTIO
|
2021-06-18 23:21:00 +08:00
|
|
|
depends on (ARM64 || X86)
|
2019-01-15 20:19:57 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select INTERVAL_TREE
|
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 23:20:58 +08:00
|
|
|
select ACPI_VIOT if ACPI
|
2019-01-15 20:19:57 +08:00
|
|
|
help
|
|
|
|
|
Para-virtualised IOMMU driver with virtio.
|
|
|
|
|
|
|
|
|
|
Say Y here if you intend to run this kernel as a guest.
|
|
|
|
|
|
2021-03-05 17:32:16 +08:00
|
|
|
config SPRD_IOMMU
|
|
|
|
|
tristate "Unisoc IOMMU Support"
|
|
|
|
|
depends on ARCH_SPRD || COMPILE_TEST
|
|
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
|
|
|
|
Support for IOMMU on Unisoc's SoCs, this IOMMU can be used by
|
|
|
|
|
Unisoc's multimedia devices, such as display, Image codec(jpeg)
|
|
|
|
|
and a few signal processors, including VSP(video), GSP(graphic),
|
|
|
|
|
ISP(image), and CPP(camera pixel processor), etc.
|
|
|
|
|
|
|
|
|
|
Say Y here if you want to use the multimedia devices listed above.
|
|
|
|
|
|
2011-06-14 21:51:54 +08:00
|
|
|
endif # IOMMU_SUPPORT
|