29 Jul, 2020
4 commits
-
More Arm SMMU updates for 5.9
- Move Arm SMMU driver files into their own subdirectory
-
…s', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'core' into next
-
Move AMD Kconfig and Makefile bits down into the amd directory
with the rest of the AMD specific files.Signed-off-by: Jerry Snitselaar
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Link: https://lore.kernel.org/r/20200630200636.48600-3-jsnitsel@redhat.com
Signed-off-by: Joerg Roedel -
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.Signed-off-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Cc: Joerg Roedel
Cc: Lu Baolu
Link: https://lore.kernel.org/r/20200630200636.48600-2-jsnitsel@redhat.com
Signed-off-by: Joerg Roedel
27 Jul, 2020
1 commit
-
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
Signed-off-by: Will Deacon
20 Jul, 2020
1 commit
-
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
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Link: https://lore.kernel.org/r/20200718193457.30046-4-vdumpa@nvidia.com
Signed-off-by: Will Deacon
10 Jun, 2020
2 commits
-
Move all files related to the Intel IOMMU driver into its own
subdirectory.Signed-off-by: Joerg Roedel
Reviewed-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Link: https://lore.kernel.org/r/20200609130303.26974-3-joro@8bytes.org -
Move all files related to the AMD IOMMU driver into its own
subdirectory.Signed-off-by: Joerg Roedel
Reviewed-by: Suravee Suthikulpanit
Reviewed-by: Jerry Snitselaar
Link: https://lore.kernel.org/r/20200609130303.26974-2-joro@8bytes.org
14 May, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/d122a8670361e36fc26b4ce2674a2223d30dc4cc.1589378833.git-series.maxime@cerno.tech
Signed-off-by: Joerg Roedel
19 Feb, 2020
1 commit
-
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
Cc: Russell King
Reported-by: Li Yang
Fixes: cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module")
Signed-off-by: Will Deacon
Reviewed-by: Robin Murphy
Signed-off-by: Joerg Roedel
23 Dec, 2019
1 commit
-
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
Tested-by: John Garry # smmu v3
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Joerg Roedel
13 Nov, 2019
1 commit
-
…diatek', 'arm/tegra', 'arm/smmu', 'x86/amd', 'x86/vt-d', 'virtio' and 'core' into next
05 Nov, 2019
1 commit
-
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.01sWith 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.54sSigned-off-by: Vivek Gautam
Reviewed-by: Robin Murphy
Reviewed-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Will Deacon
15 Oct, 2019
1 commit
-
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
Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Signed-off-by: Joerg Roedel
11 Sep, 2019
2 commits
-
… 'arm/renesas', 'x86/amd', 'x86/vt-d' and 'core' into next
-
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
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Mika Westerberg
Signed-off-by: Lu Baolu
Reviewed-by: Steven Rostedt (VMware)
Signed-off-by: Joerg Roedel
23 Aug, 2019
1 commit
-
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
Signed-off-by: Kai-Heng Feng
Signed-off-by: Joerg Roedel
19 Aug, 2019
1 commit
-
Add some nascent infrastructure for handling implementation-specific
details outside the flow of the architectural code. This will allow us
to keep mutually-incompatible vendor-specific hooks in their own files
where the respective interested parties can maintain them with minimal
chance of conflicts. As somewhat of a template, we'll start with a
general place to collect the relatively trivial existing quirks.Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
07 Jun, 2019
1 commit
-
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
Tested-by: Eric Auger
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Michael S. Tsirkin
28 Feb, 2019
1 commit
-
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
Signed-off-by: Lan Tianyu
Signed-off-by: Joerg Roedel
25 Sep, 2018
1 commit
-
Add a new config option CONFIG_INTEL_IOMMU_DEBUGFS and do the base
enabling for Intel IOMMU debugfs.Cc: Lu Baolu
Cc: Fenghua Yu
Cc: Ashok Raj
Cc: Jacob Pan
Co-Developed-by: Gayatri Kammela
Signed-off-by: Gayatri Kammela
Reviewed-by: Andy Shevchenko
Reviewed-by: Lu Baolu
Signed-off-by: Sohil Mehta
Signed-off-by: Joerg Roedel
08 Aug, 2018
1 commit
-
… 'x86/amd', 'x86/vt-d' and 'core' into next
20 Jul, 2018
1 commit
-
This adds the system wide PASID name space for the PASID
allocation. Currently we are using per IOMMU PASID name
spaces which are not suitable for some use cases. For an
example, one application (associated with a PASID) might
talk to two physical devices simultaneously while the two
devices could reside behind two different IOMMU units.Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Suggested-by: Ashok Raj
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
Reviewed-by: Liu Yi L
Reviewed-by: Peter Xu
Signed-off-by: Joerg Roedel
06 Jul, 2018
2 commits
-
Implement a skeleton framework for debugfs support in the AMD
IOMMU. Add an AMD-specific Kconfig boolean that depends upon
general enablement of DebugFS in the IOMMU.Signed-off-by: Gary R Hook
Signed-off-by: Joerg Roedel -
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
Signed-off-by: Joerg Roedel
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
15 Aug, 2017
1 commit
-
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
Tested-by: Riku Voipio
Signed-off-by: Joerg Roedel
26 Jul, 2016
1 commit
-
…arm/rockchip', 'arm/smmu' and 'core' into next
21 Jun, 2016
2 commits
-
There are only two functions left in msm_iommu_dev.c. Move it to
msm_iommu.c and delete the file.Signed-off-by: Sricharan R
Tested-by: Archit Taneja
Tested-by: Srinivas Kandagatla
Signed-off-by: Joerg Roedel -
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
Signed-off-by: Joerg Roedel
25 Feb, 2016
1 commit
-
This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
Signed-off-by: Joerg Roedel
17 Feb, 2016
1 commit
-
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
Tested-by: Yong Wu
Signed-off-by: Yong Wu
Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
14 Dec, 2015
1 commit
-
As of commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
for R-Mobile A1"), the Renesas IPMMU/IPMMUI driver is no longer used.
In theory it could still be used on SH-Mobile AG5 and R-Mobile A1 SoCs,
but that requires adding DT support to the driver, which is not
planned.Remove the driver, it can be resurrected from git history when needed.
Signed-off-by: Geert Uytterhoeven
Acked-by: Simon Horman
Signed-off-by: Joerg Roedel
06 Nov, 2015
1 commit
-
Pull iommu updates from Joerg Roedel:
"This time including:- A new IOMMU driver for s390 pci devices
- Common dma-ops support based on iommu-api for ARM64. The plan is
to use this as a basis for ARM32 and hopefully other architectures
as well in the future.- MSI support for ARM-SMMUv3
- Cleanups and dead code removal in the AMD IOMMU driver
- Better RMRR handling for the Intel VT-d driver
- Various other cleanups and small fixes"
* tag 'iommu-updates-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (41 commits)
iommu/vt-d: Fix return value check of parse_ioapics_under_ir()
iommu/vt-d: Propagate error-value from ir_parse_ioapic_hpet_scope()
iommu/vt-d: Adjust the return value of the parse_ioapics_under_ir
iommu: Move default domain allocation to iommu_group_get_for_dev()
iommu: Remove is_pci_dev() fall-back from iommu_group_get_for_dev
iommu/arm-smmu: Switch to device_group call-back
iommu/fsl: Convert to device_group call-back
iommu: Add device_group call-back to x86 iommu drivers
iommu: Add generic_device_group() function
iommu: Export and rename iommu_group_get_for_pci_dev()
iommu: Revive device_group iommu-ops call-back
iommu/amd: Remove find_last_devid_on_pci()
iommu/amd: Remove first/last_device handling
iommu/amd: Initialize amd_iommu_last_bdf for DEV_ALL
iommu/amd: Cleanup buffer allocation
iommu/amd: Remove cmd_buf_size and evt_buf_size from struct amd_iommu
iommu/amd: Align DTE flag definitions
iommu/amd: Remove old alias handling code
iommu/amd: Set alias DTE in do_attach/do_detach
iommu/amd: WARN when __[attach|detach]_device are called with irqs enabled
...
02 Nov, 2015
1 commit
-
Conflicts:
drivers/iommu/amd_iommu_types.h
15 Oct, 2015
2 commits
-
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
Signed-off-by: Joerg Roedel -
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse
06 Oct, 2015
1 commit
-
This adds an IOMMU API implementation for s390 PCI devices.
Reviewed-by: Sebastian Ott
Signed-off-by: Gerald Schaefer
Signed-off-by: Joerg Roedel
29 May, 2015
1 commit
-
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
Signed-off-by: Will Deacon
Signed-off-by: Joerg Roedel
04 Feb, 2015
1 commit
-
Conflicts:
drivers/iommu/Kconfig
drivers/iommu/Makefile