|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4 |
|
| #
5c0ebbd3 |
| 16-Oct-2024 |
Tomasz Jeznach <[email protected]> |
iommu/riscv: Add RISC-V IOMMU platform device driver
Introduce platform device driver for implementation of RISC-V IOMMU architected hardware.
Hardware interface definition located in file iommu-bi
iommu/riscv: Add RISC-V IOMMU platform device driver
Introduce platform device driver for implementation of RISC-V IOMMU architected hardware.
Hardware interface definition located in file iommu-bits.h is based on ratified RISC-V IOMMU Architecture Specification version 1.0.0.
This patch implements platform device initialization, early check and configuration of the IOMMU interfaces and enables global pass-through address translation mode (iommu_mode == BARE), without registering hardware instance in the IOMMU subsystem.
Link: https://github.com/riscv-non-isa/riscv-iommu Co-developed-by: Nick Kossifidis <[email protected]> Signed-off-by: Nick Kossifidis <[email protected]> Co-developed-by: Sebastien Boeuf <[email protected]> Signed-off-by: Sebastien Boeuf <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Tomasz Jeznach <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Link: https://lore.kernel.org/r/2f2e4530c0ee4a81385efa90f1da932f5179f3fb.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5 |
|
| #
17c51a0e |
| 12-Feb-2024 |
Lu Baolu <[email protected]> |
iommu: Separate SVA and IOPF
Add CONFIG_IOMMU_IOPF for page fault handling framework and select it from its real consumer. Move iopf function declaration from iommu-sva.h to iommu.h and remove iommu
iommu: Separate SVA and IOPF
Add CONFIG_IOMMU_IOPF for page fault handling framework and select it from its real consumer. Move iopf function declaration from iommu-sva.h to 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() into io-pgfault.c.
Export iopf_free_group() and iopf_group_response() for iopf handlers implemented in modules. Some functions are renamed with more meaningful names. No other intentional functionality changes.
Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Tested-by: Yan Zhao <[email protected]> Tested-by: Longfang Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2 |
|
| #
c4629449 |
| 13-Sep-2023 |
Jason Gunthorpe <[email protected]> |
iommu/tegra-gart: Remove tegra-gart
Thierry says this is not used anymore, and doesn't think it makes sense as an iommu driver. The HW it supports is about 10 years old now and newer HW uses differe
iommu/tegra-gart: Remove tegra-gart
Thierry says this is not used anymore, and doesn't think it makes sense as an iommu driver. The HW it supports is about 10 years old now and newer HW uses different IOMMU drivers.
As this is the only driver with a GART approach, and it doesn't really meet the driver expectations from the IOMMU core, let's just remove it so 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 <[email protected]> Cc: Dmitry Osipenko <[email protected]> Acked-by: Thierry Reding <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4 |
|
| #
99b5726b |
| 22-Mar-2023 |
Jason Gunthorpe <[email protected]> |
iommu: Remove ioasid infrastructure
This has no use anymore, delete it all.
Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Jason Gunt
iommu: Remove ioasid infrastructure
This has no use anymore, delete it all.
Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8 |
|
| #
2ff4bed7 |
| 29-Nov-2022 |
Jason Gunthorpe <[email protected]> |
iommufd: File descriptor, context, kconfig and makefiles
This is the basic infrastructure of a new miscdevice to hold the iommufd IOCTL API.
It provides: - A miscdevice to create file descriptors
iommufd: File descriptor, context, kconfig and makefiles
This is the basic infrastructure of a new miscdevice to hold the iommufd IOCTL API.
It provides: - A miscdevice to create file descriptors to run the IOCTL interface over
- A table based ioctl dispatch and centralized extendable pre-validation step
- An xarray mapping userspace ID's to kernel objects. The design has multiple inter-related objects held within in a single IOMMUFD fd
- A simple usage count to build a graph of object relations and protect against hostile userspace racing ioctls
The only IOCTL provided in this patch is the generic 'destroy any object by handle' operation.
Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Eric Auger <[email protected]> Tested-by: Nicolin Chen <[email protected]> Tested-by: Yi Liu <[email protected]> Tested-by: Lixiao Yang <[email protected]> Tested-by: Matthew Rosato <[email protected]> Signed-off-by: Yi Liu <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
show more ...
|
|
Revision tags: v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4 |
|
| #
757636ed |
| 31-Oct-2022 |
Lu Baolu <[email protected]> |
iommu: Rename iommu-sva-lib.{c,h}
Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code for SVA implementation in iommu core.
Signed-off-by: Lu Baolu <[email protected]> Review
iommu: Rename iommu-sva-lib.{c,h}
Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code for SVA implementation in iommu core.
Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jean-Philippe Brucker <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Tested-by: Zhangfei Gao <[email protected]> Tested-by: Tony Zhu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6 |
|
| #
745ef109 |
| 16-Sep-2022 |
Janne Grunau <[email protected]> |
iommu/io-pgtable: Move Apple DART support to its own file
The pte format used by the DARTs found in the Apple M1 (t8103) is not fully compatible with io-pgtable-arm. The 24 MSB are used for subpage
iommu/io-pgtable: Move Apple DART support to its own file
The pte format used by the DARTs found in the Apple M1 (t8103) is not fully compatible with io-pgtable-arm. The 24 MSB are used for subpage protection (mapping only parts of page) and conflict with the address mask. In addition bit 1 is not available for tagging entries but disables subpage protection. Subpage protection could be useful to support a CPU granule of 4k with the fixed IOMMU page size of 16k.
The DARTs found on Apple M1 Pro/Max/Ultra use another different pte format which is even less compatible. To support an output address size of 42 bit the address is shifted down by 4. Subpage protection is mandatory and bit 1 signifies uncached mappings used by the display controller.
It would be advantageous to share code for all known Apple DART variants to support common features. The page table allocator for DARTs is less complex since it uses a two levels of translation table without support for huge pages.
Signed-off-by: Janne Grunau <[email protected]> Acked-by: Robin Murphy <[email protected]> Acked-by: Sven Peter <[email protected]> Acked-by: Hector Martin <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ joro: Fix compile warning in __dart_alloc_pages()] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4 |
|
| #
7ba56472 |
| 07-Feb-2022 |
Fenghua Yu <[email protected]> |
iommu/sva: Rename CONFIG_IOMMU_SVA_LIB to CONFIG_IOMMU_SVA
This CONFIG option originally only referred to the Shared Virtual Address (SVA) library. But it is now also used for non-library portions o
iommu/sva: Rename CONFIG_IOMMU_SVA_LIB to CONFIG_IOMMU_SVA
This CONFIG option originally only referred to the Shared Virtual Address (SVA) library. But it is now also used for non-library portions of code.
Drop the "_LIB" suffix so that there is just one configuration option for all code relating to SVA.
Signed-off-by: Fenghua Yu <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5 |
|
| #
46d1fb07 |
| 03-Aug-2021 |
Sven Peter <[email protected]> |
iommu/dart: Add DART iommu driver
Apple's new SoCs use iommus for almost all peripherals. These Device Address Resolution Tables must be setup before these peripherals can act as DMA masters.
Teste
iommu/dart: Add DART iommu driver
Apple's new SoCs use iommus for almost all peripherals. These Device Address Resolution Tables must be setup before these peripherals can act as DMA masters.
Tested-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: Sven Peter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6 |
|
| #
fc36479d |
| 01-Apr-2021 |
Jean-Philippe Brucker <[email protected]> |
iommu: Add a page fault handler
Some systems allow devices to handle I/O Page Faults in the core mm. For example systems implementing the PCIe PRI extension or Arm SMMU stall model. Infrastructure f
iommu: Add a page fault handler
Some systems allow devices to handle I/O Page Faults in the core mm. For example systems implementing the PCIe PRI extension or Arm SMMU stall model. Infrastructure for reporting these recoverable page faults was added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device fault report API"). Add a page fault handler for host SVA.
IOMMU driver can now instantiate several fault workqueues and link them to IOPF-capable devices. Drivers can choose between a single global workqueue, one per IOMMU device, one per low-level fault queue, one per domain, etc.
When it receives a fault event, most commonly in an IRQ handler, the IOMMU driver reports the fault using iommu_report_device_fault(), which calls the registered handler. The page fault handler then calls the mm fault handler, and reports either success or failure with iommu_page_response(). After the handler succeeds, the hardware retries the access.
The iopf_param pointer could be embedded into iommu_fault_param. But putting iopf_param into the iommu_param structure allows us not to care about ordering between calls to iopf_queue_add_device() and iommu_register_device_fault_handler().
Tested-by: Lu Baolu <[email protected]> Reviewed-by: Eric Auger <[email protected]> Reviewed-by: Jacob Pan <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2 |
|
| #
b23e4fc4 |
| 05-Mar-2021 |
Chunyan Zhang <[email protected]> |
iommu: add Unisoc IOMMU basic driver
This IOMMU module can be used by Unisoc's multimedia devices, such as display, Image codec(jpeg) and a few signal processors, including VSP(video), GSP(graphic),
iommu: add Unisoc IOMMU basic driver
This IOMMU module 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.
Signed-off-by: Chunyan Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3 |
|
| #
cfc78dfd |
| 06-Nov-2020 |
Jean-Philippe Brucker <[email protected]> |
iommu/sva: Add PASID helpers
Let IOMMU drivers allocate a single PASID per mm. Store the mm in the IOASID set to allow refcounting and searching mm by PASID, when handling an I/O page fault.
Signed
iommu/sva: Add PASID helpers
Let IOMMU drivers allocate a single PASID per mm. Store the mm in the IOASID set to allow refcounting and searching mm by PASID, when handling an I/O page fault.
Signed-off-by: Jean-Philippe Brucker <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
show more ...
|
|
Revision tags: v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4 |
|
| #
cbe94c6e |
| 30-Jun-2020 |
Jerry Snitselaar <[email protected]> |
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 Snitse
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 <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Suravee Suthikulpanit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
| #
ab65ba57 |
| 30-Jun-2020 |
Jerry Snitselaar <[email protected]> |
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 S
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 <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
| #
e86d1aa8 |
| 24-Jul-2020 |
Will Deacon <[email protected]> |
iommu/arm-smmu: Move Arm SMMU drivers into their own subdirectory
The Arm SMMU drivers are getting fat on vendor value-add, so move them to their own subdirectory out of the way of the other IOMMU d
iommu/arm-smmu: Move Arm SMMU drivers into their own subdirectory
The Arm SMMU drivers are getting fat on vendor value-add, so move them to their own subdirectory out of the way of the other IOMMU drivers.
Suggested-by: Joerg Roedel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
show more ...
|
| #
aab5a1c8 |
| 18-Jul-2020 |
Krishna Reddy <[email protected]> |
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
NVIDIA's Tegra194 SoC has three ARM MMU-500 instances. It uses two of the ARM MMU-500s together to interleave IOVA accesses across the
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
NVIDIA's Tegra194 SoC has three ARM MMU-500 instances. It uses two of the ARM MMU-500s together to interleave IOVA accesses across them and must be programmed identically. This implementation supports programming the two ARM MMU-500s that must be programmed identically.
The third ARM MMU-500 instance is supported by standard arm-smmu.c driver itself.
Signed-off-by: Krishna Reddy <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Pritesh Raithatha <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc3, v5.8-rc2, v5.8-rc1 |
|
| #
672cf6df |
| 09-Jun-2020 |
Joerg Roedel <[email protected]> |
iommu/vt-d: Move Intel IOMMU driver into subdirectory
Move all files related to the Intel IOMMU driver into its own subdirectory.
Signed-off-by: Joerg Roedel <[email protected]> Reviewed-by: Jerry Sn
iommu/vt-d: Move Intel IOMMU driver into subdirectory
Move all files related to the Intel IOMMU driver into its own subdirectory.
Signed-off-by: Joerg Roedel <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
ad8694ba |
| 09-Jun-2020 |
Joerg Roedel <[email protected]> |
iommu/amd: Move AMD IOMMU driver into subdirectory
Move all files related to the AMD IOMMU driver into its own subdirectory.
Signed-off-by: Joerg Roedel <[email protected]> Reviewed-by: Suravee Suthi
iommu/amd: Move AMD IOMMU driver into subdirectory
Move all files related to the AMD IOMMU driver into its own subdirectory.
Signed-off-by: Joerg Roedel <[email protected]> Reviewed-by: Suravee Suthikulpanit <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v5.7, v5.7-rc7, v5.7-rc6 |
|
| #
4100b8c2 |
| 13-May-2020 |
Maxime Ripard <[email protected]> |
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 c
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 <[email protected]> Link: https://lore.kernel.org/r/d122a8670361e36fc26b4ce2674a2223d30dc4cc.1589378833.git-series.maxime@cerno.tech Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3 |
|
| #
ab362fff |
| 18-Feb-2020 |
Will Deacon <[email protected]> |
iommu/arm-smmu: Restore naming of driver parameter prefix
Extending the Arm SMMU driver to allow for modular builds changed KBUILD_MODNAME to be "arm_smmu_mod" so that a single module could be built
iommu/arm-smmu: Restore naming of driver parameter prefix
Extending the Arm SMMU driver to allow for modular builds changed KBUILD_MODNAME to be "arm_smmu_mod" so that a single module could be built from the multiple existing object files without the need to rename any source files.
This inadvertently changed the name of the driver parameters, which may lead to runtime issues if bootloaders are relying on the old names for correctness (e.g. "arm-smmu.disable_bypass=0").
Although MODULE_PARAM_PREFIX can be overridden to restore the old naming for builtin parameters, only the new name is matched by modprobe and so loading the driver as a module would cause parameters specified on the kernel command line to be ignored. Instead, rename "arm_smmu_mod" to "arm_smmu". Whilst it's a bit of a bodge, this allows us to create a single module without renaming any files and makes use of the fact that underscores and hyphens can be used interchangeably in parameter names.
Cc: Robin Murphy <[email protected]> Cc: Russell King <[email protected]> Reported-by: Li Yang <[email protected]> Fixes: cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module") Signed-off-by: Will Deacon <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3 |
|
| #
cd221bd2 |
| 19-Dec-2019 |
Will Deacon <[email protected]> |
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 drive
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 <[email protected]> Tested-by: John Garry <[email protected]> # smmu v3 Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1 |
|
| #
759aaa10 |
| 20-Sep-2019 |
Vivek Gautam <[email protected]> |
iommu: arm-smmu-impl: Add sdm845 implementation hook
Add reset hook for sdm845 based platforms to turn off the wait-for-safe sequence.
Understanding how wait-for-safe logic affects USB and UFS perf
iommu: arm-smmu-impl: Add sdm845 implementation hook
Add reset hook for sdm845 based platforms to turn off the wait-for-safe sequence.
Understanding how wait-for-safe logic affects USB and UFS performance on MTP845 and DB845 boards:
Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic to address under-performance issues in real-time clients, such as Display, and Camera. On receiving an invalidation requests, the SMMU forwards SAFE request to these clients and waits for SAFE ack signal from real-time clients. The SAFE signal from such clients is used to qualify the start of invalidation. This logic is controlled by chicken bits, one for each - MDP (display), IFE0, and IFE1 (camera), that can be accessed only from secure software on sdm845.
This configuration, however, degrades the performance of non-real time clients, such as USB, and UFS etc. This happens because, with wait-for-safe logic enabled the hardware tries to throttle non-real time clients while waiting for SAFE ack signals from real-time clients.
On mtp845 and db845 devices, with wait-for-safe logic enabled by the bootloaders we see degraded performance of USB and UFS when kernel enables the smmu stage-1 translations for these clients. Turn off this wait-for-safe logic from the kernel gets us back the perf of USB and UFS devices until we re-visit this when we start seeing perf issues on display/camera on upstream supported SDM845 platforms. The bootloaders on these boards implement secure monitor callbacks to handle a specific command - QCOM_SCM_SVC_SMMU_PROGRAM with which the logic can be toggled.
There are other boards such as cheza whose bootloaders don't enable this logic. Such boards don't implement callbacks to handle the specific SCM call so disabling this logic for such boards will be a no-op.
This change is inspired by the downstream change from Patrick Daly to address performance issues with display and camera by handling this wait-for-safe within separte io-pagetable ops to do TLB maintenance. So a big thanks to him for the change and for all the offline discussions.
Without this change the UFS reads are pretty slow: $ time dd if=/dev/sda of=/dev/zero bs=1048576 count=10 conv=sync 10+0 records in 10+0 records out 10485760 bytes (10.0MB) copied, 22.394903 seconds, 457.2KB/s real 0m 22.39s user 0m 0.00s sys 0m 0.01s
With this change they are back to rock! $ time dd if=/dev/sda of=/dev/zero bs=1048576 count=300 conv=sync 300+0 records in 300+0 records out 314572800 bytes (300.0MB) copied, 1.030541 seconds, 291.1MB/s real 0m 1.03s user 0m 0.00s sys 0m 0.54s
Signed-off-by: Vivek Gautam <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Sai Prakash Ranjan <[email protected]> Signed-off-by: Will Deacon <[email protected]>
show more ...
|
| #
fa83433c |
| 02-Oct-2019 |
Jean-Philippe Brucker <[email protected]> |
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 ad
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 <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Reviewed-by: Jean-Philippe Brucker <[email protected]> Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.3, v5.3-rc8 |
|
| #
3b53034c |
| 06-Sep-2019 |
Lu Baolu <[email protected]> |
iommu/vt-d: Add trace events for device dma map/unmap
This adds trace support for the Intel IOMMU driver. It also declares some events which could be used to trace the events when an IOVA is being m
iommu/vt-d: Add trace events for device dma map/unmap
This adds trace support for the Intel IOMMU driver. It also declares some events which could be used to trace the events when an IOVA is being mapped or unmapped in a domain.
Cc: Ashok Raj <[email protected]> Cc: Jacob Pan <[email protected]> Cc: Kevin Tian <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|
|
Revision tags: v5.3-rc7, v5.3-rc6 |
|
| #
93d05155 |
| 21-Aug-2019 |
Kai-Heng Feng <[email protected]> |
iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems
Raven Ridge systems may have malfunction touchpad or hang at boot if incorrect IVRS IOAPIC is provided by BIOS.
Users already found corr
iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems
Raven Ridge systems may have malfunction touchpad or hang at boot if incorrect IVRS IOAPIC is provided by BIOS.
Users already found correct "ivrs_ioapic=" values, let's put them inside kernel to workaround buggy BIOS.
BugLink: https://bugs.launchpad.net/bugs/1795292 BugLink: https://bugs.launchpad.net/bugs/1837688 Reported-by: kbuild test robot <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
show more ...
|