Changes in Kconfig

ba40f9dc - iommu/mediatek-v1: Support COMPILE_TEST

Tue, 11 Mar 2025 14:15:56 +0000

iommu/mediatek-v1: Support COMPILE_TESTAdd COMPILE_TEST support to Mediatek v1 so I have less chance ofbreaking it again in future. This just needs the ARM dma-iommu APIstubbing out for now.Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/a8d7c0b4393b360ce556f5f15e229d1e2fe73c83.1741702556.git.robin.murphy@arm.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

96093fe5 - irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by irqchips that need it

Thu, 20 Feb 2025 01:31:39 +0000

irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by irqchips that need itCurrently, IRQ_MSI_IOMMU is selected if DMA_IOMMU is available to providean implementation for iommu_dma_prepare/compose_msi_msg(). However, it'llmake more sense for irqchips that call prepare/compose to select it, andthat will trigger all the additional code and data to be compiled intothe kernel.If IRQ_MSI_IOMMU is selected with no IOMMU side implementation, then theprepare/compose() will be NOP stubs.If IRQ_MSI_IOMMU is not selected by an irqchip, then the related code onthe iommu side is compiled out.Link: https://patch.msgid.link/r/a2620f67002c5cdf974e89ca3bf905f5c0817be6.1740014950.git.nicolinc@nvidia.comSigned-off-by: Nicolin Chen Reviewed-by: Thomas Gleixner Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/iommu/Kconfig

ef4144b1 - iommu/arm-smmu: Re-enable context caching in smmu reset operation

Thu, 12 Dec 2024 15:13:58 +0000

iommu/arm-smmu: Re-enable context caching in smmu reset operationDefault MMU-500 reset operation disables context caching in prefetchbuffer. It is however expected for context banks using the ACTLRregister to retain their prefetch value during reset and runtimesuspend.Add config 'ARM_SMMU_MMU_500_CPRE_ERRATA' to gate this errata workaroundin default MMU-500 reset operation which defaults to 'Y' and provideoption to disable workaround for context caching in prefetch buffer asand when needed.Suggested-by: Will Deacon Signed-off-by: Bibek Kumar Patro Link: https://lore.kernel.org/r/20241212151402.159102-2-quic_bibekkum@quicinc.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

6912ec91 - iommu/arm-smmu-v3: Support IOMMU_GET_HW_INFO via struct arm_smmu_hw_info

Thu, 31 Oct 2024 00:20:49 +0000

iommu/arm-smmu-v3: Support IOMMU_GET_HW_INFO via struct arm_smmu_hw_infoFor virtualization cases the IDR/IIDR/AIDR values of the actual SMMUinstance need to be available to the VMM so it can construct anappropriate vSMMUv3 that reflects the correct HW capabilities.For userspace page tables these values are required to constrain the validvalues within the CD table and the IOPTEs.The kernel does not sanitize these values. If building a VMM thenuserspace is required to only forward bits into a VM that it knows it canimplement. Some bits will also require a VMM to detect if appropriatekernel support is available such as for ATS and BTM.Start a new file and kconfig for the advanced iommufd support. This letsit be compiled out for kernels that are not intended to supportvirtualization, and allows distros to leave it disabled until they areshipping a matching qemu too.Tested-by: Nicolin Chen Signed-off-by: Nicolin Chen Reviewed-by: Kevin Tian Reviewed-by: Jerry Snitselaar Reviewed-by: Donald Dutile Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/5-v4-9e99b76f3518+3a8-smmuv3_nesting_jgg@nvidia.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

5c0ebbd3 - iommu/riscv: Add RISC-V IOMMU platform device driver

Wed, 16 Oct 2024 06:52:14 +0000

iommu/riscv: Add RISC-V IOMMU platform device driverIntroduce platform device driver for implementation of RISC-V IOMMUarchitected hardware.Hardware interface definition located in file iommu-bits.h is based onratified RISC-V IOMMU Architecture Specification version 1.0.0.This patch implements platform device initialization, early check andconfiguration of the IOMMU interfaces and enables global pass-throughaddress translation mode (iommu_mode == BARE), without registeringhardware instance in the IOMMU subsystem.Link: https://github.com/riscv-non-isa/riscv-iommuCo-developed-by: Nick Kossifidis Signed-off-by: Nick Kossifidis Co-developed-by: Sebastien Boeuf Signed-off-by: Sebastien Boeuf Reviewed-by: Lu Baolu Signed-off-by: Tomasz Jeznach Acked-by: Palmer Dabbelt Link: https://lore.kernel.org/r/2f2e4530c0ee4a81385efa90f1da932f5179f3fb.1729059707.git.tjeznach@rivosinc.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

918eb5c8 - iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV

Thu, 29 Aug 2024 22:34:37 +0000

iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQVNVIDIA's Tegra241 Soc has a CMDQ-Virtualization (CMDQV) hardware, extendingthe standard ARM SMMU v3 IP to support multiple VCMDQs with virtualizationcapabilities. In terms of command queue, they are very like a standard SMMUCMDQ (or ECMDQs), but only support CS_NONE in the CS field of CMD_SYNC.Add a new tegra241-cmdqv driver, and insert its structure pointer into theexisting arm_smmu_device, and then add related function calls in the SMMUv3driver to interact with the CMDQV driver.In the CMDQV driver, add a minimal part for the in-kernel support: reserveVINTF0 for in-kernel use, and assign some of the VCMDQs to the VINTF0, andselect one VCMDQ based on the current CPU ID to execute supported commands.This multi-queue design for in-kernel use gives some limited improvements:up to 20% reduction of invalidation time was measured by a multi-threadedDMA unmap benchmark, compared to a single queue.The other part of the CMDQV driver will be user-space support that gives ahypervisor running on the host OS to talk to the driver for virtualizationuse cases, allowing VMs to use VCMDQs without trappings, i.e. no VM Exits.This is designed based on IOMMUFD, and its RFC series is also under review.It will provide a guest OS a bigger improvement: 70% to 90% reductions ofTLB invalidation time were measured by DMA unmap tests running in a guest,compared to nested SMMU CMDQ (with trappings).As the initial version, the CMDQV driver only supports ACPI configurations.Signed-off-by: Nate Watterson Reviewed-by: Jason Gunthorpe Co-developed-by: Nicolin Chen Signed-off-by: Nicolin Chen Link: https://lore.kernel.org/r/dce50490b2c10b7254fb36aa73ed7ffd812b283a.1724970714.git.nicolinc@nvidia.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

b5c58b2f - dma-mapping: direct calls for dma-iommu

Wed, 24 Jul 2024 18:04:49 +0000

dma-mapping: direct calls for dma-iommuDirectly call into dma-iommu just like we have been doing for dma-directfor a while. This avoids the indirect call overhead for IOMMU ops andremoves the need to have DMA ops entirely for many common configurations.Signed-off-by: Leon Romanovsky Signed-off-by: Leon Romanovsky Acked-by: Greg Kroah-Hartman Acked-by: Robin Murphy Signed-off-by: Christoph Hellwig List of files: /linux-6.15/drivers/iommu/Kconfig

25c776dd - iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mapping

Wed, 03 Jul 2024 10:16:04 +0000

iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mappingIf io-pgtable quirk flag indicates support for hardware update ofdirty state, enable HA/HD bits in the SMMU CD and also set the DBMbit in the page descriptor.Now report the dirty page tracking capability of SMMUv3 andselect IOMMUFD_DRIVER for ARM_SMMU_V3 if IOMMUFD is enabled.Co-developed-by: Keqian Zhu Signed-off-by: Keqian Zhu Signed-off-by: Kunkun Jiang Signed-off-by: Joao Martins Reviewed-by: Ryan Roberts Reviewed-by: Jason Gunthorpe Reviewed-by: Nicolin Chen Signed-off-by: Shameer Kolothum Link: https://lore.kernel.org/r/20240703101604.2576-6-shameerali.kolothum.thodi@huawei.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

da55da5a - iommu/arm-smmu-v3: Make the kunit into a module

Tue, 07 May 2024 13:21:10 +0000

iommu/arm-smmu-v3: Make the kunit into a moduleIt turns out kconfig has problems ensuring the SMMU module and the KUNITmodule are consistently y/m to allow linking. It will permit KUNIT to be amodule while SMMU is built in.Also, Fedora apparently enables kunit on production kernels.So, put the entire kunit in its own module using theVISIBLE_IF_KUNIT/EXPORT_SYMBOL_IF_KUNIT machinery. This keeps it out ofvmlinus on Fedora and makes the kconfig work in the normal way. There isno cost if kunit is disabled.Fixes: 56e1a4cc2588 ("iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry")Reported-by: Thorsten Leemhuis Link: https://lore.kernel.org/all/aeea8546-5bce-4c51-b506-5d2008e52fef@leemhuis.infoSigned-off-by: Jason Gunthorpe Tested-by: Thorsten Leemhuis Acked-by: Will Deacon Link: https://lore.kernel.org/r/0-v1-24cba6c0f404+2ae-smmu_kunit_module_jgg@nvidia.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

56e1a4cc - iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry

Tue, 30 Apr 2024 17:21:41 +0000

iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entryAdd tests for some of the more common STE update operations that we expectto see, as well as some artificial STE updates to test the edges ofarm_smmu_write_entry. These also serve as a record of which commonoperation is expected to be hitless, and how many syncs they require.arm_smmu_write_entry implements a generic algorithm that updates an STE/CDto any other abritrary STE/CD configuration. The update requires asequence of write+sync operations with some invariants that must be heldtrue after each sync. arm_smmu_write_entry lends itself well tounit-testing since the function's interaction with the STE/CD is alreadyabstracted by input callbacks that we can hook to introspect into thesequence of operations. We can use these hooks to guarantee thatinvariants are held throughout the entire update operation.Link: https://lore.kernel.org/r/20240106083617.1173871-3-mshavit@google.comTested-by: Nicolin Chen Signed-off-by: Michael Shavit Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/9-v9-5040dc602008+177d7-smmuv3_newapi_p2_jgg@nvidia.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

0928fc15 - iommu/arm-smmu-qcom: Don't build debug features as a kernel module

Wed, 01 May 2024 14:27:29 +0000

iommu/arm-smmu-qcom: Don't build debug features as a kernel moduleThe Qualcomm TBU debug support introduced by 414ecb030870("iommu/arm-smmu-qcom-debug: Add support for TBUs") provides its owndriver initialisation function, which breaks the link when the core SMMUdriver is built as a module: ld.lld: error: duplicate symbol: init_module >>> defined at arm-smmu.c >>> drivers/iommu/arm/arm-smmu/arm-smmu.o:(init_module) >>> defined at arm-smmu-qcom-debug.c >>> drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.o:(.init.text+0x4)Since we're late in the cycle, just make the debug features depend on anon-modular SMMU driver for now while the initialisation is reworked tohang off qcom_smmu_impl_init().Signed-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

414ecb03 - iommu/arm-smmu-qcom-debug: Add support for TBUs

Wed, 17 Apr 2024 13:37:26 +0000

iommu/arm-smmu-qcom-debug: Add support for TBUsOperating the TBUs (Translation Buffer Units) from Linux on Qualcommplatforms can help with debugging context faults. To help with that,the TBUs can run ATOS (Address Translation Operations) to manuallytrigger address translation of IOVA to physical address in hardwareand provide more details when a context fault happens.The driver will control the resources needed by the TBU to allowrunning the debug operations such as ATOS, check for outstandingtransactions, do snapshot capture etc.Signed-off-by: Georgi Djakov Link: https://lore.kernel.org/r/20240417133731.2055383-3-quic_c_gdjako@quicinc.comSigned-off-by: Will Deacon List of files: /linux-6.15/drivers/iommu/Kconfig

70bad345 - iommu: Fix compilation without CONFIG_IOMMU_INTEL

Thu, 07 Mar 2024 19:44:19 +0000

iommu: Fix compilation without CONFIG_IOMMU_INTELWhen the kernel is comiled with CONFIG_IRQ_REMAP=y but withoutCONFIG_IOMMU_INTEL compilation fails since commit def054b01a8678 with anundefined reference to device_rbtree_find(). This patch makes sure thatintel specific code is only compiled with CONFIG_IOMMU_INTEL=y.Signed-off-by: Bert Karwatzki Fixes: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if target device isn't present")Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/20240307194419.15801-1-spasswolf@web.deSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

17c51a0e - iommu: Separate SVA and IOPF

Mon, 12 Feb 2024 01:22:21 +0000

iommu: Separate SVA and IOPFAdd CONFIG_IOMMU_IOPF for page fault handling framework and select itfrom its real consumer. Move iopf function declaration from iommu-sva.hto iommu.h and remove iommu-sva.h as it's empty now.Consolidate all SVA related code into iommu-sva.c:- Move iommu_sva_domain_alloc() from iommu.c to iommu-sva.c.- Move sva iopf handling code from io-pgfault.c to iommu-sva.c.Consolidate iommu_report_device_fault() and iommu_page_response() intoio-pgfault.c.Export iopf_free_group() and iopf_group_response() for iopf handlersimplemented in modules. Some functions are renamed with more meaningfulnames. No other intentional functionality changes.Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Tested-by: Yan Zhao Tested-by: Longfang Liu Link: https://lore.kernel.org/r/20240212012227.119381-11-baolu.lu@linux.intel.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

18368ee2 - iommu/msm-iommu: don't limit the driver too much

Sat, 16 Dec 2023 16:26:58 +0000

iommu/msm-iommu: don't limit the driver too muchIn preparation of dropping most of ARCH_QCOM subtypes, stop limiting thedriver just to those machines. Allow it to be built for any 32-bitQualcomm platform (ARCH_QCOM).Acked-by: Robin Murphy Acked-by: Joerg Roedel Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231216162700.863456-2-dmitry.baryshkov@linaro.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/iommu/Kconfig

8f23f5db - iommu: Change kconfig around IOMMU_SVA

Fri, 27 Oct 2023 00:05:20 +0000

iommu: Change kconfig around IOMMU_SVALinus suggested that the kconfig here is confusing:https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/Let's break it into three kconfigs controlling distinct things: - CONFIG_IOMMU_MM_DATA controls if the mm_struct has the additional fields for the IOMMU. Currently only PASID, but later patches store a struct iommu_mm_data * - CONFIG_ARCH_HAS_CPU_PASID controls if the arch needs the scheduling bit for keeping track of the ENQCMD instruction. x86 will select this if IOMMU_SVA is enabled - IOMMU_SVA controls if the IOMMU core compiles in the SVA support code for iommu driver use and the IOMMU exported APIThis way ARM will not enable CONFIG_ARCH_HAS_CPU_PASIDSigned-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20231027000525.1278806-2-tina.zhang@intel.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

8c9c727b - vfio: Move iova_bitmap into iommufd

Tue, 24 Oct 2023 13:50:53 +0000

vfio: Move iova_bitmap into iommufdBoth VFIO and IOMMUFD will need iova bitmap for storing dirties and walkingthe user bitmaps, so move to the common dependency into IOMMUFD. In doingso, create the symbol IOMMUFD_DRIVER which designates the builtin code thatwill be used by drivers when selected. Today this means MLX5_VFIO_PCI andPDS_VFIO_PCI. IOMMU drivers will do the same (in future patches) whensupporting dirty tracking and select IOMMUFD_DRIVER accordingly.Given that the symbol maybe be disabled, add header definitions iniova_bitmap.h for when IOMMUFD_DRIVER=nLink: https://lore.kernel.org/r/20231024135109.73787-3-joao.m.martins@oracle.comSigned-off-by: Joao Martins Reviewed-by: Jason Gunthorpe Reviewed-by: Brett Creeley Reviewed-by: Kevin Tian Reviewed-by: Alex Williamson Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/iommu/Kconfig

c76c067e - s390/pci: Use dma-iommu layer

Thu, 28 Sep 2023 14:31:37 +0000

s390/pci: Use dma-iommu layerWhile s390 already has a standard IOMMU driver and previous changes haveadded I/O TLB flushing operations this driver is currently only used foruser-space PCI access such as vfio-pci. For the DMA API s390 insteadutilizes its own implementation in arch/s390/pci/pci_dma.c which drivesthe same hardware and shares some code but requires a complex andfragile hand over between DMA API and IOMMU API use of a device anddespite code sharing still leads to significant duplication andmaintenance effort. Let's utilize the common code DMAP APIimplementation from drivers/iommu/dma-iommu.c instead allowing us toget rid of arch/s390/pci/pci_dma.c.Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Link: https://lore.kernel.org/r/20230928-dma_iommu-v13-3-9e5fc4dacc36@linux.ibm.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

c4629449 - iommu/tegra-gart: Remove tegra-gart

Wed, 13 Sep 2023 13:43:39 +0000

iommu/tegra-gart: Remove tegra-gartThierry says this is not used anymore, and doesn't think it makes sense asan iommu driver. The HW it supports is about 10 years old now and newer HWuses different IOMMU drivers.As this is the only driver with a GART approach, and it doesn't reallymeet the driver expectations from the IOMMU core, let's just remove itso we don't have to think about how to make it fit in.It has a number of identified problems: - The assignment of iommu_groups doesn't match the HW behavior - It claims to have an UNMANAGED domain but it is really an IDENTITY domain with a translation aperture. This is inconsistent with the core expectation for security sensitive operations - It doesn't implement a SW page table under struct iommu_domain so * It can't accept a map until the domain is attached * It forgets about all maps after the domain is detached * It doesn't clear the HW of maps once the domain is detached (made worse by having the wrong groups)Cc: Thierry Reding Cc: Dmitry Osipenko Acked-by: Thierry Reding Reviewed-by: Lu Baolu Reviewed-by: Jerry Snitselaar Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/6-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidia.comSigned-off-by: Joerg Roedel List of files: /linux-6.15/drivers/iommu/Kconfig

cf8e8658 - arch: Remove Itanium (IA-64) architecture

Thu, 20 Oct 2022 13:54:33 +0000

arch: Remove Itanium (IA-64) architectureThe Itanium architecture is obsolete, and an informal survey [0] revealsthat any residual use of Itanium hardware in production is mostly HP-UXor OpenVMS based. The use of Linux on Itanium appears to be limited toenthusiasts that occasionally boot a fresh Linux kernel to see whetherthings are still working as intended, and perhaps to churn out somedistro packages that are rarely used in practice.None of the original companies behind Itanium still produce or supportany hardware or software for the architecture, and it is listed as'Orphaned' in the MAINTAINERS file, as apparently, none of the engineersthat contributed on behalf of those companies (nor anyone else, for thatmatter) have been willing to support or maintain the architectureupstream or even be responsible for applying the odd fix. The Intelfirmware team removed all IA-64 support from the Tianocore/EDK2reference implementation of EFI in 2018. (Itanium is the originalarchitecture for which EFI was developed, and the way Linux supports itdeviates significantly from other architectures.) Some distros, such asDebian and Gentoo, still maintain [unofficial] ia64 ports, but many havedropped support years ago.While the argument is being made [1] that there is a 'for the commongood' angle to being able to build and run existing projects such as theGrid Community Toolkit [2] on Itanium for interoperability testing, thefact remains that none of those projects are known to be deployed onLinux/ia64, and very few people actually have access to such a system inthe first place. Even if there were ways imaginable in which Linux/ia64could be put to good use today, what matters is whether anyone isactually doing that, and this does not appear to be the case.There are no emulators widely available, and so boot testing Itanium isgenerally infeasible for ordinary contributors. GCC still supports IA-64but its compile farm [3] no longer has any IA-64 machines. GLIBC wouldlike to get rid of IA-64 [4] too because it would permit some overduecode cleanups. In summary, the benefits to the ecosystem of having IA-64be part of it are mostly theoretical, whereas the maintenance overheadof keeping it supported is real.So let's rip off the band aid, and remove the IA-64 arch code entirely.This follows the timeline proposed by the Debian/ia64 maintainer [5],which removes support in a controlled manner, leaving IA-64 in a knowngood state in the most recent LTS release. Other projects will followonce the kernel support is removed.[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/[1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/[2] https://gridcf.org/gct-docs/latest/index.html[3] https://cfarm.tetaneutral.net/machines/list/[4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/Acked-by: Tony Luck Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/iommu/Kconfig