27 Sep, 2017
1 commit
-
The definition of map_sg was split during a recent addition to iommu_ops.
Put it back together.Fixes: add02cfdc9bc ("iommu: Introduce Interface for IOMMU TLB Flushing")
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
01 Sep, 2017
1 commit
-
…iatek', 'arm/tegra', 'arm/qcom', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd', 's390' and 'core' into next
31 Aug, 2017
1 commit
-
With the current IOMMU-API the hardware TLBs have to be
flushed in every iommu_ops->unmap() call-back.For unmapping large amounts of address space, like it
happens when a KVM domain with assigned devices is
destroyed, this causes thousands of unnecessary TLB flushes
in the IOMMU hardware because the unmap call-back runs for
every unmapped physical page.With the TLB Flush Interface and the new iommu_unmap_fast()
function introduced here the need to clean the hardware TLBs
is removed from the unmapping code-path. Users of
iommu_unmap_fast() have to explicitly call the TLB-Flush
functions to sync the page-table changes to the hardware.Three functions for TLB-Flushes are introduced:
* iommu_flush_tlb_all() - Flushes all TLB entries
associated with that
domain. TLBs entries are
flushed when this function
returns.* iommu_tlb_range_add() - This will add a given
range to the flush queue
for this domain.* iommu_tlb_sync() - Flushes all queued ranges from
the hardware TLBs. Returns when
the flush is finished.The semantic of this interface is intentionally similar to
the iommu_gather_ops from the io-pgtable code.Cc: Alex Williamson
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Joerg Roedel
16 Aug, 2017
1 commit
-
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.Signed-off-by: Baoquan He
Signed-off-by: Joerg Roedel
15 Aug, 2017
1 commit
-
The struct iommu_device has a 'struct device' embedded into
it, not as a pointer, but the whole struct. In the
conversion of the iommu drivers to use struct iommu_device
it was forgotten that the relase function for that struct
device simply calls kfree() on the pointer.This frees memory that was never allocated and causes memory
corruption.To fix this issue, use a pointer to struct device instead of
embedding the whole struct. This needs some updates in the
iommu sysfs code as well as the Intel VT-d and AMD IOMMU
driver.Reported-by: Sebastian Ott
Fixes: 39ab9555c241 ('iommu: Add sysfs bindings for struct iommu_device')
Cc: stable@vger.kernel.org # >= v4.11
Signed-off-by: Joerg Roedel
26 Jul, 2017
1 commit
-
Commit 7d3002cc8c16 ("iommu/core: split mapping to page sizes as supported
by the hardware") replaced 'int gfp_order' with a 'size_t size' of
iommu_map / iommu_unmap function arguments, but missed the function
prototypes for the disabled CONFIG_IOMMU_API case, let's correct them
for consistency.Signed-off-by: Dmitry Osipenko
Signed-off-by: Joerg Roedel
05 May, 2017
1 commit
-
…mu', 'arm/core', 'x86/vt-d', 'x86/amd' and 'core' into next
29 Apr, 2017
1 commit
-
It is not needed there anymore. All places needing it are
fixed.Signed-off-by: Joerg Roedel
27 Apr, 2017
2 commits
-
The function is in no fast-path, there is no need for it to
be static inline in a header file. This also removes the
need to include iommu trace-points in iommu.h.Signed-off-by: Joerg Roedel
-
We make use of 'struct device' in iommu.h, so include
device.h to make it available explicitly.Re-order the other headers while at it.
Signed-off-by: Joerg Roedel
06 Apr, 2017
1 commit
-
This is a fairly subtle thing - let's make sure it's described as
clearly as possible to avoid potential misunderstandings.Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
22 Mar, 2017
1 commit
-
The introduction of reserved regions has left a couple of rough edges
which we could do with sorting out sooner rather than later. Since we
are not yet addressing the potential dynamic aspect of software-managed
reservations and presenting them at arbitrary fixed addresses, it is
incongruous that we end up displaying hardware vs. software-managed MSI
regions to userspace differently, especially since ARM-based systems may
actually require one or the other, or even potentially both at once,
(which iommu-dma currently has no hope of dealing with at all). Let's
resolve the former user-visible inconsistency ASAP before the ABI has
been baked into a kernel release, in a way that also lays the groundwork
for the latter shortcoming to be addressed by follow-up patches.For clarity, rename the software-managed type to IOMMU_RESV_SW_MSI, use
IOMMU_RESV_MSI to describe the hardware type, and document everything a
little bit. Since the x86 MSI remapping hardware falls squarely under
this meaning of IOMMU_RESV_MSI, apply that type to their regions as well,
so that we tell the same story to userspace across all platforms.Secondly, as the various region types require quite different handling,
and it really makes little sense to ever try combining them, convert the
bitfield-esque #defines to a plain enum in the process before anyone
gets the wrong impression.Fixes: d30ddcaa7b02 ("iommu: Add a new type field in iommu_resv_region")
Reviewed-by: Eric Auger
CC: Alex Williamson
CC: David Woodhouse
CC: kvm@vger.kernel.org
Signed-off-by: Robin Murphy
Signed-off-by: Joerg Roedel
10 Feb, 2017
7 commits
-
…atek', 'arm/core', 'x86/vt-d' and 'core' into next
-
And also move its remaining functionality to
iommu_device_register() and 'struct iommu_device'.Cc: Rob Herring
Cc: Frank Rowand
Cc: Matthias Brugger
Cc: Marek Szyprowski
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Joerg Roedel -
Allow to store a fwnode in 'struct iommu_device';
Signed-off-by: Joerg Roedel
-
This makes the interface more consistent with
iommu_device_sysfs_add/remove.Signed-off-by: Joerg Roedel
-
There is currently support for iommu sysfs bindings, but
those need to be implemented in the IOMMU drivers. Add a
more generic version of this by adding a struct device to
struct iommu_device and use that for the sysfs bindings.Also convert the AMD and Intel IOMMU driver to make use of
it.Signed-off-by: Joerg Roedel
-
This struct represents one hardware iommu in the iommu core
code. For now it only has the iommu-ops associated with it,
but that will be extended soon.The register/unregister interface is also added, as well as
making use of it in the Intel and AMD IOMMU drivers.Signed-off-by: Joerg Roedel
-
Rename the function to iommu_ops_from_fwnode(), because that
is what the function actually does. The new name is much
more descriptive about what the function does.Signed-off-by: Joerg Roedel
30 Jan, 2017
1 commit
-
…/will/linux into arm/core
23 Jan, 2017
4 commits
-
Introduce iommu_get_group_resv_regions whose role consists in
enumerating all devices from the group and collecting their
reserved regions. The list is sorted and overlaps between
regions of the same type are handled by merging the regions.Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
Signed-off-by: Will Deacon -
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
Signed-off-by: Will Deacon -
We introduce a new field to differentiate the reserved region
types and specialize the apply_resv_region implementation.Legacy direct mapped regions have IOMMU_RESV_DIRECT type.
We introduce 2 new reserved memory types:
- IOMMU_RESV_MSI will characterize MSI regions that are mapped
- IOMMU_RESV_RESERVED characterize regions that cannot by mapped.Signed-off-by: Eric Auger
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
Signed-off-by: Will Deacon -
We want to extend the callbacks used for dm regions and
use them for reserved regions. Reserved regions can be
- directly mapped regions
- regions that cannot be iommu mapped (PCI host bridge windows, ...)
- MSI regions (because they belong to another address space or because
they are not translated by the IOMMU and need special handling)So let's rename the struct and also the callbacks.
Signed-off-by: Eric Auger
Acked-by: Robin Murphy
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
Signed-off-by: Will Deacon
19 Jan, 2017
1 commit
-
Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.Reviewed-by: Robin Murphy
Tested-by: Robin Murphy
Signed-off-by: Mitchel Humpherys
Acked-by: Will Deacon
Signed-off-by: Will Deacon
07 Dec, 2016
1 commit
29 Nov, 2016
1 commit
-
The of_iommu_{set/get}_ops() API is used to associate a device
tree node with a specific set of IOMMU operations. The same
kernel interface is required on systems booting with ACPI, where
devices are not associated with a device tree node, therefore
the interface requires generalization.The struct device fwnode member represents the fwnode token associated
with the device and the struct it points at is firmware specific;
regardless, it is initialized on both ACPI and DT systems and makes an
ideal candidate to use it to associate a set of IOMMU operations to a
given device, through its struct device.fwnode member pointer, paving
the way for representing per-device iommu_ops (ie an iommu instance
associated with a device).Convert the DT specific of_iommu_{set/get}_ops() interface to
use struct device.fwnode as a look-up token, making the interface
usable on ACPI systems and rename the data structures and the
registration API so that they are made to represent their usage
more clearly.Signed-off-by: Lorenzo Pieralisi
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
Reviewed-by: Tomasz Nowicki
Tested-by: Hanjun Guo
Tested-by: Tomasz Nowicki
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Robin Murphy
Cc: Joerg Roedel
Signed-off-by: Will Deacon
15 Nov, 2016
1 commit
-
iommu_group_get_for_dev() expects that the IOMMU driver's device_group
callback return a group with a reference held for the given device.
Whilst allocating a new group is fine, and pci_device_group() correctly
handles reusing an existing group, there is no general means for IOMMU
drivers doing their own group lookup to take additional references on an
existing group pointer without having to also store device pointers or
resort to elaborate trickery.Add an IOMMU-driver-specific function to fill the hole.
Acked-by: Sricharan R
Signed-off-by: Robin Murphy
Signed-off-by: Joerg Roedel
16 Sep, 2016
1 commit
-
Introduce a common structure to hold the per-device firmware data that
most IOMMU drivers need to keep track of. This enables us to configure
much of that data from common firmware code, and consolidate a lot of
the equivalent implementations, device look-up tables, etc. which are
currently strewn across IOMMU drivers.This will also be enable us to address the outstanding "multiple IOMMUs
on the platform bus" problem by tweaking IOMMU API calls to prefer
dev->fwspec->ops before falling back to dev->bus->iommu_ops, and thus
gracefully handle those troublesome systems which we currently cannot.As the first user, hook up the OF IOMMU configuration mechanism. The
driver-defined nature of DT cells means that we still need the drivers
to translate and add the IDs themselves, but future users such as the
much less free-form ACPI IORT will be much simpler and self-contained.CC: Greg Kroah-Hartman
Suggested-by: Will Deacon
Signed-off-by: Robin Murphy
Signed-off-by: Will Deacon
13 Jul, 2016
1 commit
-
This new call-back will be used by the iommu driver to do
reserve the given dm_region in its iova space before the
mapping is created.The call-back is temporary until the dma-ops implementation
is part of the common iommu code.Signed-off-by: Joerg Roedel
10 May, 2016
1 commit
-
…mu', 'core' and 'x86/amd' into next
09 May, 2016
2 commits
-
Many IOMMUs support multiple page table formats, meaning that any given
domain may only support a subset of the hardware page sizes presented in
iommu_ops->pgsize_bitmap. There are also certain use-cases where the
creator of a domain may want to control which page sizes are used, for
example to force the use of hugepage mappings to reduce pagetable walk
depth.To this end, add a per-domain pgsize_bitmap to represent the subset of
page sizes actually in use, to make it possible for domains with
different requirements to coexist.Signed-off-by: Will Deacon
[rm: hijacked and rebased original patch with new commit message]
Signed-off-by: Robin Murphy
Acked-by: Will Deacon
Signed-off-by: Joerg Roedel -
The priv field from iommu_ops is a hangover from the of_dma_configure
series and isn't actually used. Remove it before it has chance to
spread.Signed-off-by: Will Deacon
Acked-by: Laurent Pinchart
Acked-by: Will Deacon
Signed-off-by: Joerg Roedel
07 Apr, 2016
1 commit
-
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.Signed-off-by: Robin Murphy
Signed-off-by: Joerg Roedel
05 Apr, 2016
1 commit
-
iommu drivers that support the standard DT bindings use a of_xlate
callback pointer, but that is only part of struct iommu_ops when
CONFIG_OF_IOMMU is enabled, leading to build errors in randconfig
builds when that is not provided:drivers/iommu/mtk_iommu.c:497:2: error: unknown field 'of_xlate' specified in initializer
.of_xlate = mtk_iommu_of_xlate,
^
drivers/iommu/mtk_iommu.c:497:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.of_xlate = mtk_iommu_of_xlate,
^~~~~~~~~~~~~~~~~~
drivers/iommu/mtk_iommu.c:497:14: note: (near initialization for 'mtk_iommu_ops.domain_get_attr')We can work around it by adding more #ifdefs in each driver, but
it seems nicer to just allow setting the pointer even if it is
unused. This makes the driver code look nicer, and it gives better
compile-time coverage when test building on other architectures.Signed-off-by: Arnd Bergmann
Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver")
Reviewed-by: Robin Murphy
Signed-off-by: Joerg Roedel
29 Jan, 2016
1 commit
-
Update the comments around struct iommu_ops to match
current state and fix a few typos while at it.Signed-off-by: Magnus Damm
Signed-off-by: Joerg Roedel
22 Oct, 2015
3 commits
-
This function can be used as a device_group call-back and
just allocates one iommu-group per device.Signed-off-by: Joerg Roedel
-
Rename that function to pci_device_group() and export it, so
that IOMMU drivers can use it as their device_group
call-back.Signed-off-by: Joerg Roedel
-
That call-back is currently unused, change it into a
call-back function for finding the right IOMMU group for a
device.
This is a first step to remove the hard-coded PCI dependency
in the iommu-group code.Signed-off-by: Joerg Roedel
15 Oct, 2015
1 commit
-
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