2019-05-30 02:57:47 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2008-11-26 19:02:33 +03:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2007-2008 Advanced Micro Devices, Inc.
|
|
|
|
|
* Author: Joerg Roedel <joerg.roedel@amd.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __LINUX_IOMMU_H
|
|
|
|
|
#define __LINUX_IOMMU_H
|
|
|
|
|
|
2017-04-26 16:34:06 +03:00
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/types.h>
|
2011-06-09 01:29:11 +04:00
|
|
|
#include <linux/errno.h>
|
2013-04-19 05:38:04 +04:00
|
|
|
#include <linux/err.h>
|
2014-08-27 19:15:59 +04:00
|
|
|
#include <linux/of.h>
|
2019-10-02 22:42:43 +03:00
|
|
|
#include <linux/ioasid.h>
|
2019-06-03 17:57:47 +03:00
|
|
|
#include <uapi/linux/iommu.h>
|
2011-06-09 01:29:11 +04:00
|
|
|
|
2013-11-05 19:59:53 +04:00
|
|
|
#define IOMMU_READ (1 << 0)
|
|
|
|
|
#define IOMMU_WRITE (1 << 1)
|
|
|
|
|
#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
|
2014-10-13 17:06:16 +04:00
|
|
|
#define IOMMU_NOEXEC (1 << 3)
|
2016-04-05 14:39:30 +03:00
|
|
|
#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
|
2017-01-06 16:28:08 +03:00
|
|
|
/*
|
2017-01-27 15:22:54 +03:00
|
|
|
* Where the bus hardware includes a privilege level as part of its access type
|
|
|
|
|
* markings, and certain devices are capable of issuing transactions marked as
|
|
|
|
|
* either 'supervisor' or 'user', the IOMMU_PRIV flag requests that the other
|
|
|
|
|
* given permission flags only apply to accesses at the higher privilege level,
|
|
|
|
|
* and that unprivileged transactions should have as little access as possible.
|
|
|
|
|
* This would usually imply the same permissions as kernel mappings on the CPU,
|
|
|
|
|
* if the IOMMU page table format is equivalent.
|
2017-01-06 16:28:08 +03:00
|
|
|
*/
|
|
|
|
|
#define IOMMU_PRIV (1 << 5)
|
2008-11-26 19:02:33 +03:00
|
|
|
|
2011-09-06 18:03:26 +04:00
|
|
|
struct iommu_ops;
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
struct iommu_group;
|
2011-08-26 18:48:26 +04:00
|
|
|
struct bus_type;
|
2008-11-26 19:02:33 +03:00
|
|
|
struct device;
|
2011-09-13 23:25:23 +04:00
|
|
|
struct iommu_domain;
|
2012-08-03 17:55:41 +04:00
|
|
|
struct notifier_block;
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
struct iommu_sva;
|
2019-06-03 17:57:47 +03:00
|
|
|
struct iommu_fault_event;
|
2011-09-13 23:25:23 +04:00
|
|
|
|
|
|
|
|
/* iommu fault flags */
|
|
|
|
|
#define IOMMU_FAULT_READ 0x0
|
|
|
|
|
#define IOMMU_FAULT_WRITE 0x1
|
|
|
|
|
|
|
|
|
|
typedef int (*iommu_fault_handler_t)(struct iommu_domain *,
|
2012-05-21 21:20:05 +04:00
|
|
|
struct device *, unsigned long, int, void *);
|
2019-06-03 17:57:47 +03:00
|
|
|
typedef int (*iommu_dev_fault_handler_t)(struct iommu_fault *, void *);
|
2008-11-26 19:02:33 +03:00
|
|
|
|
2012-01-26 22:40:53 +04:00
|
|
|
struct iommu_domain_geometry {
|
|
|
|
|
dma_addr_t aperture_start; /* First address that can be mapped */
|
|
|
|
|
dma_addr_t aperture_end; /* Last address that can be mapped */
|
|
|
|
|
bool force_aperture; /* DMA only allowed in mappable range? */
|
|
|
|
|
};
|
|
|
|
|
|
2015-03-26 15:43:05 +03:00
|
|
|
/* Domain feature flags */
|
|
|
|
|
#define __IOMMU_DOMAIN_PAGING (1U << 0) /* Support for iommu_map/unmap */
|
|
|
|
|
#define __IOMMU_DOMAIN_DMA_API (1U << 1) /* Domain for use in DMA-API
|
|
|
|
|
implementation */
|
|
|
|
|
#define __IOMMU_DOMAIN_PT (1U << 2) /* Domain is identity mapped */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This are the possible domain-types
|
|
|
|
|
*
|
|
|
|
|
* IOMMU_DOMAIN_BLOCKED - All DMA is blocked, can be used to isolate
|
|
|
|
|
* devices
|
|
|
|
|
* IOMMU_DOMAIN_IDENTITY - DMA addresses are system physical addresses
|
|
|
|
|
* IOMMU_DOMAIN_UNMANAGED - DMA mappings managed by IOMMU-API user, used
|
|
|
|
|
* for VMs
|
|
|
|
|
* IOMMU_DOMAIN_DMA - Internally used for DMA-API implementations.
|
|
|
|
|
* This flag allows IOMMU drivers to implement
|
|
|
|
|
* certain optimizations for these domains
|
|
|
|
|
*/
|
|
|
|
|
#define IOMMU_DOMAIN_BLOCKED (0U)
|
|
|
|
|
#define IOMMU_DOMAIN_IDENTITY (__IOMMU_DOMAIN_PT)
|
|
|
|
|
#define IOMMU_DOMAIN_UNMANAGED (__IOMMU_DOMAIN_PAGING)
|
|
|
|
|
#define IOMMU_DOMAIN_DMA (__IOMMU_DOMAIN_PAGING | \
|
|
|
|
|
__IOMMU_DOMAIN_DMA_API)
|
|
|
|
|
|
2008-11-26 19:02:33 +03:00
|
|
|
struct iommu_domain {
|
2015-03-26 15:43:05 +03:00
|
|
|
unsigned type;
|
2014-06-27 11:03:12 +04:00
|
|
|
const struct iommu_ops *ops;
|
2016-04-07 20:42:06 +03:00
|
|
|
unsigned long pgsize_bitmap; /* Bitmap of page sizes in use */
|
2011-09-13 23:25:23 +04:00
|
|
|
iommu_fault_handler_t handler;
|
2012-05-21 21:20:05 +04:00
|
|
|
void *handler_token;
|
2012-01-26 22:40:53 +04:00
|
|
|
struct iommu_domain_geometry geometry;
|
2015-10-01 22:13:58 +03:00
|
|
|
void *iova_cookie;
|
2008-11-26 19:02:33 +03:00
|
|
|
};
|
|
|
|
|
|
2014-09-03 20:34:04 +04:00
|
|
|
enum iommu_cap {
|
|
|
|
|
IOMMU_CAP_CACHE_COHERENCY, /* IOMMU can enforce cache coherent DMA
|
|
|
|
|
transactions */
|
|
|
|
|
IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */
|
2014-10-13 17:06:17 +04:00
|
|
|
IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */
|
2014-09-03 20:34:04 +04:00
|
|
|
};
|
2009-03-18 10:33:06 +03:00
|
|
|
|
2017-01-19 23:57:48 +03:00
|
|
|
/* These are the possible reserved region types */
|
iommu: Disambiguate MSI region types
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 <eric.auger@redhat.com>
CC: Alex Williamson <alex.williamson@redhat.com>
CC: David Woodhouse <dwmw2@infradead.org>
CC: kvm@vger.kernel.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-03-16 20:00:16 +03:00
|
|
|
enum iommu_resv_type {
|
|
|
|
|
/* Memory regions which must be mapped 1:1 at all times */
|
|
|
|
|
IOMMU_RESV_DIRECT,
|
2019-06-03 09:53:35 +03:00
|
|
|
/*
|
|
|
|
|
* Memory regions which are advertised to be 1:1 but are
|
|
|
|
|
* commonly considered relaxable in some conditions,
|
|
|
|
|
* for instance in device assignment use case (USB, Graphics)
|
|
|
|
|
*/
|
|
|
|
|
IOMMU_RESV_DIRECT_RELAXABLE,
|
iommu: Disambiguate MSI region types
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 <eric.auger@redhat.com>
CC: Alex Williamson <alex.williamson@redhat.com>
CC: David Woodhouse <dwmw2@infradead.org>
CC: kvm@vger.kernel.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-03-16 20:00:16 +03:00
|
|
|
/* Arbitrary "never map this or give it to a device" address ranges */
|
|
|
|
|
IOMMU_RESV_RESERVED,
|
|
|
|
|
/* Hardware MSI region (untranslated) */
|
|
|
|
|
IOMMU_RESV_MSI,
|
|
|
|
|
/* Software-managed MSI translation window */
|
|
|
|
|
IOMMU_RESV_SW_MSI,
|
|
|
|
|
};
|
2017-01-19 23:57:48 +03:00
|
|
|
|
2015-05-28 19:41:33 +03:00
|
|
|
/**
|
2017-01-19 23:57:47 +03:00
|
|
|
* struct iommu_resv_region - descriptor for a reserved memory region
|
2015-05-28 19:41:33 +03:00
|
|
|
* @list: Linked list pointers
|
|
|
|
|
* @start: System physical start address of the region
|
|
|
|
|
* @length: Length of the region in bytes
|
|
|
|
|
* @prot: IOMMU Protection flags (READ/WRITE/...)
|
2017-01-19 23:57:48 +03:00
|
|
|
* @type: Type of the reserved region
|
2015-05-28 19:41:33 +03:00
|
|
|
*/
|
2017-01-19 23:57:47 +03:00
|
|
|
struct iommu_resv_region {
|
2015-05-28 19:41:33 +03:00
|
|
|
struct list_head list;
|
|
|
|
|
phys_addr_t start;
|
|
|
|
|
size_t length;
|
|
|
|
|
int prot;
|
iommu: Disambiguate MSI region types
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 <eric.auger@redhat.com>
CC: Alex Williamson <alex.williamson@redhat.com>
CC: David Woodhouse <dwmw2@infradead.org>
CC: kvm@vger.kernel.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-03-16 20:00:16 +03:00
|
|
|
enum iommu_resv_type type;
|
2015-05-28 19:41:33 +03:00
|
|
|
};
|
|
|
|
|
|
2021-04-01 18:47:12 +03:00
|
|
|
/**
|
|
|
|
|
* enum iommu_dev_features - Per device IOMMU features
|
|
|
|
|
* @IOMMU_DEV_FEAT_AUX: Auxiliary domain feature
|
|
|
|
|
* @IOMMU_DEV_FEAT_SVA: Shared Virtual Addresses
|
|
|
|
|
* @IOMMU_DEV_FEAT_IOPF: I/O Page Faults such as PRI or Stall. Generally
|
|
|
|
|
* enabling %IOMMU_DEV_FEAT_SVA requires
|
|
|
|
|
* %IOMMU_DEV_FEAT_IOPF, but some devices manage I/O Page
|
|
|
|
|
* Faults themselves instead of relying on the IOMMU. When
|
|
|
|
|
* supported, this feature must be enabled before and
|
|
|
|
|
* disabled after %IOMMU_DEV_FEAT_SVA.
|
|
|
|
|
*
|
|
|
|
|
* Device drivers query whether a feature is supported using
|
|
|
|
|
* iommu_dev_has_feature(), and enable it using iommu_dev_enable_feature().
|
|
|
|
|
*/
|
iommu: Add APIs for multiple domains per device
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the security consideration. With finer-granularity
DMA isolation, subsets of a PCI function can be isolated
from each others by the IOMMU. As a result, there is a
request in software to attach multiple domains to a physical
PCI device. One example of such use model is the Intel
Scalable IOV [1] [2]. The Intel vt-d 3.0 spec [3] introduces
the scalable mode which enables PASID granularity DMA
isolation.
This adds the APIs to support multiple domains per device.
In order to ease the discussions, we call it 'a domain in
auxiliary mode' or simply 'auxiliary domain' when multiple
domains are attached to a physical device.
The APIs include:
* iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
- Detect both IOMMU and PCI endpoint devices supporting
the feature (aux-domain here) without the host driver
dependency.
* iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)
- Check the enabling status of the feature (aux-domain
here). The aux-domain interfaces are available only
if this returns true.
* iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX)
- Enable/disable device specific aux-domain feature.
* iommu_aux_attach_device(domain, dev)
- Attaches @domain to @dev in the auxiliary mode. Multiple
domains could be attached to a single device in the
auxiliary mode with each domain representing an isolated
address space for an assignable subset of the device.
* iommu_aux_detach_device(domain, dev)
- Detach @domain which has been attached to @dev in the
auxiliary mode.
* iommu_aux_get_pasid(domain, dev)
- Return ID used for finer-granularity DMA translation.
For the Intel Scalable IOV usage model, this will be
a PASID. The device which supports Scalable IOV needs
to write this ID to the device register so that DMA
requests could be tagged with a right PASID prefix.
This has been updated with the latest proposal from Joerg
posted here [5].
Many people involved in discussions of this design.
Kevin Tian <kevin.tian@intel.com>
Liu Yi L <yi.l.liu@intel.com>
Ashok Raj <ashok.raj@intel.com>
Sanjay Kumar <sanjay.k.kumar@intel.com>
Jacob Pan <jacob.jun.pan@linux.intel.com>
Alex Williamson <alex.williamson@redhat.com>
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Joerg Roedel <joro@8bytes.org>
and some discussions can be found here [4] [5].
[1] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
[2] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
[3] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
[4] https://lkml.org/lkml/2018/7/26/4
[5] https://www.spinics.net/lists/iommu/msg31874.html
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Suggested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-03-25 04:30:28 +03:00
|
|
|
enum iommu_dev_features {
|
2021-04-01 18:47:12 +03:00
|
|
|
IOMMU_DEV_FEAT_AUX,
|
|
|
|
|
IOMMU_DEV_FEAT_SVA,
|
|
|
|
|
IOMMU_DEV_FEAT_IOPF,
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define IOMMU_PASID_INVALID (-1U)
|
|
|
|
|
|
2011-09-06 18:48:40 +04:00
|
|
|
#ifdef CONFIG_IOMMU_API
|
|
|
|
|
|
2019-07-02 18:43:48 +03:00
|
|
|
/**
|
|
|
|
|
* struct iommu_iotlb_gather - Range information for a pending IOTLB flush
|
|
|
|
|
*
|
|
|
|
|
* @start: IOVA representing the start of the range to be flushed
|
2021-01-07 15:29:06 +03:00
|
|
|
* @end: IOVA representing the end of the range to be flushed (inclusive)
|
2019-07-02 18:43:48 +03:00
|
|
|
* @pgsize: The interval at which to perform the flush
|
|
|
|
|
*
|
|
|
|
|
* This structure is intended to be updated by multiple calls to the
|
|
|
|
|
* ->unmap() function in struct iommu_ops before eventually being passed
|
|
|
|
|
* into ->iotlb_sync().
|
|
|
|
|
*/
|
|
|
|
|
struct iommu_iotlb_gather {
|
|
|
|
|
unsigned long start;
|
|
|
|
|
unsigned long end;
|
|
|
|
|
size_t pgsize;
|
2020-11-24 11:20:51 +03:00
|
|
|
struct page *freelist;
|
2019-07-02 18:43:48 +03:00
|
|
|
};
|
|
|
|
|
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
/**
|
|
|
|
|
* struct iommu_ops - iommu ops and capabilities
|
2016-01-19 08:28:48 +03:00
|
|
|
* @capable: check capability
|
|
|
|
|
* @domain_alloc: allocate iommu domain
|
|
|
|
|
* @domain_free: free iommu domain
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
* @attach_dev: attach device to an iommu domain
|
|
|
|
|
* @detach_dev: detach device from an iommu domain
|
|
|
|
|
* @map: map a physically contiguous memory region to an iommu domain
|
|
|
|
|
* @unmap: unmap a physically contiguous memory region from an iommu domain
|
2019-02-11 18:50:33 +03:00
|
|
|
* @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
|
2019-02-20 16:00:52 +03:00
|
|
|
* @iotlb_sync_map: Sync mappings created recently using @map to the hardware
|
2018-12-04 21:27:34 +03:00
|
|
|
* @iotlb_sync: Flush all queued ranges from the hardware TLBs and empty flush
|
2017-08-23 16:50:04 +03:00
|
|
|
* queue
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
* @iova_to_phys: translate iova to physical address
|
2020-04-29 16:36:45 +03:00
|
|
|
* @probe_device: Add device to iommu driver handling
|
|
|
|
|
* @release_device: Remove device from iommu driver handling
|
|
|
|
|
* @probe_finalize: Do final setup work after the device is added to an IOMMU
|
|
|
|
|
* group and attached to the groups domain
|
2016-01-19 08:28:48 +03:00
|
|
|
* @device_group: find iommu group for a particular device
|
2021-04-01 18:52:52 +03:00
|
|
|
* @enable_nesting: Enable nesting
|
2021-04-01 18:52:55 +03:00
|
|
|
* @set_pgtable_quirks: Set io page table quirks (IO_PGTABLE_QUIRK_*)
|
2017-01-19 23:57:47 +03:00
|
|
|
* @get_resv_regions: Request list of reserved regions for a device
|
|
|
|
|
* @put_resv_regions: Free list of reserved regions for a device
|
|
|
|
|
* @apply_resv_region: Temporary helper call-back for iova reserved ranges
|
2014-08-27 19:15:59 +04:00
|
|
|
* @of_xlate: add OF master IDs to iommu grouping
|
2019-02-20 16:00:53 +03:00
|
|
|
* @is_attach_deferred: Check if domain attach should be deferred from iommu
|
|
|
|
|
* driver init to device driver init (default no)
|
iommu: Add APIs for multiple domains per device
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the security consideration. With finer-granularity
DMA isolation, subsets of a PCI function can be isolated
from each others by the IOMMU. As a result, there is a
request in software to attach multiple domains to a physical
PCI device. One example of such use model is the Intel
Scalable IOV [1] [2]. The Intel vt-d 3.0 spec [3] introduces
the scalable mode which enables PASID granularity DMA
isolation.
This adds the APIs to support multiple domains per device.
In order to ease the discussions, we call it 'a domain in
auxiliary mode' or simply 'auxiliary domain' when multiple
domains are attached to a physical device.
The APIs include:
* iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
- Detect both IOMMU and PCI endpoint devices supporting
the feature (aux-domain here) without the host driver
dependency.
* iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)
- Check the enabling status of the feature (aux-domain
here). The aux-domain interfaces are available only
if this returns true.
* iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX)
- Enable/disable device specific aux-domain feature.
* iommu_aux_attach_device(domain, dev)
- Attaches @domain to @dev in the auxiliary mode. Multiple
domains could be attached to a single device in the
auxiliary mode with each domain representing an isolated
address space for an assignable subset of the device.
* iommu_aux_detach_device(domain, dev)
- Detach @domain which has been attached to @dev in the
auxiliary mode.
* iommu_aux_get_pasid(domain, dev)
- Return ID used for finer-granularity DMA translation.
For the Intel Scalable IOV usage model, this will be
a PASID. The device which supports Scalable IOV needs
to write this ID to the device register so that DMA
requests could be tagged with a right PASID prefix.
This has been updated with the latest proposal from Joerg
posted here [5].
Many people involved in discussions of this design.
Kevin Tian <kevin.tian@intel.com>
Liu Yi L <yi.l.liu@intel.com>
Ashok Raj <ashok.raj@intel.com>
Sanjay Kumar <sanjay.k.kumar@intel.com>
Jacob Pan <jacob.jun.pan@linux.intel.com>
Alex Williamson <alex.williamson@redhat.com>
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Joerg Roedel <joro@8bytes.org>
and some discussions can be found here [4] [5].
[1] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
[2] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
[3] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
[4] https://lkml.org/lkml/2018/7/26/4
[5] https://www.spinics.net/lists/iommu/msg31874.html
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Suggested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-03-25 04:30:28 +03:00
|
|
|
* @dev_has/enable/disable_feat: per device entries to check/enable/disable
|
|
|
|
|
* iommu specific features.
|
|
|
|
|
* @dev_feat_enabled: check enabled feature
|
|
|
|
|
* @aux_attach/detach_dev: aux-domain specific attach/detach entries.
|
|
|
|
|
* @aux_get_pasid: get the pasid given an aux-domain
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
* @sva_bind: Bind process address space to device
|
|
|
|
|
* @sva_unbind: Unbind process address space from device
|
|
|
|
|
* @sva_get_pasid: Get PASID associated to a SVA handle
|
2019-06-03 17:57:49 +03:00
|
|
|
* @page_response: handle page request response
|
2019-10-02 22:42:40 +03:00
|
|
|
* @cache_invalidate: invalidate translation caches
|
2019-10-02 22:42:43 +03:00
|
|
|
* @sva_bind_gpasid: bind guest pasid and mm
|
|
|
|
|
* @sva_unbind_gpasid: unbind guest pasid and mm
|
2020-04-29 16:36:40 +03:00
|
|
|
* @def_domain_type: device default domain type, return value:
|
|
|
|
|
* - IOMMU_DOMAIN_IDENTITY: must use an identity domain
|
|
|
|
|
* - IOMMU_DOMAIN_DMA: must use a dma domain
|
|
|
|
|
* - 0: use the default setting
|
2019-12-19 15:03:41 +03:00
|
|
|
* @pgsize_bitmap: bitmap of all possible supported page sizes
|
|
|
|
|
* @owner: Driver module providing these ops
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
*/
|
2008-11-26 19:02:33 +03:00
|
|
|
struct iommu_ops {
|
2014-09-03 20:47:25 +04:00
|
|
|
bool (*capable)(enum iommu_cap);
|
2015-03-26 15:43:04 +03:00
|
|
|
|
|
|
|
|
/* Domain allocation and freeing by the iommu driver */
|
2015-03-26 15:43:05 +03:00
|
|
|
struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
|
2015-03-26 15:43:04 +03:00
|
|
|
void (*domain_free)(struct iommu_domain *);
|
|
|
|
|
|
2008-11-26 19:02:33 +03:00
|
|
|
int (*attach_dev)(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
void (*detach_dev)(struct iommu_domain *domain, struct device *dev);
|
2010-01-21 18:32:27 +03:00
|
|
|
int (*map)(struct iommu_domain *domain, unsigned long iova,
|
2019-09-08 19:56:38 +03:00
|
|
|
phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
|
2011-11-10 13:32:25 +04:00
|
|
|
size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
|
2019-07-02 18:44:06 +03:00
|
|
|
size_t size, struct iommu_iotlb_gather *iotlb_gather);
|
2017-08-23 16:50:04 +03:00
|
|
|
void (*flush_iotlb_all)(struct iommu_domain *domain);
|
2021-01-07 15:29:04 +03:00
|
|
|
void (*iotlb_sync_map)(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
|
size_t size);
|
2019-07-02 18:44:06 +03:00
|
|
|
void (*iotlb_sync)(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_iotlb_gather *iotlb_gather);
|
2013-03-28 23:53:58 +04:00
|
|
|
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
|
2020-04-29 16:36:45 +03:00
|
|
|
struct iommu_device *(*probe_device)(struct device *dev);
|
|
|
|
|
void (*release_device)(struct device *dev);
|
|
|
|
|
void (*probe_finalize)(struct device *dev);
|
2015-10-22 00:51:36 +03:00
|
|
|
struct iommu_group *(*device_group)(struct device *dev);
|
2021-04-01 18:52:52 +03:00
|
|
|
int (*enable_nesting)(struct iommu_domain *domain);
|
2021-04-01 18:52:55 +03:00
|
|
|
int (*set_pgtable_quirks)(struct iommu_domain *domain,
|
|
|
|
|
unsigned long quirks);
|
2013-01-29 17:26:20 +04:00
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
/* Request/Free a list of reserved regions for a device */
|
|
|
|
|
void (*get_resv_regions)(struct device *dev, struct list_head *list);
|
|
|
|
|
void (*put_resv_regions)(struct device *dev, struct list_head *list);
|
|
|
|
|
void (*apply_resv_region)(struct device *dev,
|
|
|
|
|
struct iommu_domain *domain,
|
|
|
|
|
struct iommu_resv_region *region);
|
2015-05-28 19:41:33 +03:00
|
|
|
|
2014-08-27 19:15:59 +04:00
|
|
|
int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
|
2017-08-09 11:33:40 +03:00
|
|
|
bool (*is_attach_deferred)(struct iommu_domain *domain, struct device *dev);
|
2014-08-27 19:15:59 +04:00
|
|
|
|
iommu: Add APIs for multiple domains per device
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the security consideration. With finer-granularity
DMA isolation, subsets of a PCI function can be isolated
from each others by the IOMMU. As a result, there is a
request in software to attach multiple domains to a physical
PCI device. One example of such use model is the Intel
Scalable IOV [1] [2]. The Intel vt-d 3.0 spec [3] introduces
the scalable mode which enables PASID granularity DMA
isolation.
This adds the APIs to support multiple domains per device.
In order to ease the discussions, we call it 'a domain in
auxiliary mode' or simply 'auxiliary domain' when multiple
domains are attached to a physical device.
The APIs include:
* iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
- Detect both IOMMU and PCI endpoint devices supporting
the feature (aux-domain here) without the host driver
dependency.
* iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)
- Check the enabling status of the feature (aux-domain
here). The aux-domain interfaces are available only
if this returns true.
* iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX)
- Enable/disable device specific aux-domain feature.
* iommu_aux_attach_device(domain, dev)
- Attaches @domain to @dev in the auxiliary mode. Multiple
domains could be attached to a single device in the
auxiliary mode with each domain representing an isolated
address space for an assignable subset of the device.
* iommu_aux_detach_device(domain, dev)
- Detach @domain which has been attached to @dev in the
auxiliary mode.
* iommu_aux_get_pasid(domain, dev)
- Return ID used for finer-granularity DMA translation.
For the Intel Scalable IOV usage model, this will be
a PASID. The device which supports Scalable IOV needs
to write this ID to the device register so that DMA
requests could be tagged with a right PASID prefix.
This has been updated with the latest proposal from Joerg
posted here [5].
Many people involved in discussions of this design.
Kevin Tian <kevin.tian@intel.com>
Liu Yi L <yi.l.liu@intel.com>
Ashok Raj <ashok.raj@intel.com>
Sanjay Kumar <sanjay.k.kumar@intel.com>
Jacob Pan <jacob.jun.pan@linux.intel.com>
Alex Williamson <alex.williamson@redhat.com>
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Joerg Roedel <joro@8bytes.org>
and some discussions can be found here [4] [5].
[1] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
[2] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
[3] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
[4] https://lkml.org/lkml/2018/7/26/4
[5] https://www.spinics.net/lists/iommu/msg31874.html
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Suggested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-03-25 04:30:28 +03:00
|
|
|
/* Per device IOMMU features */
|
|
|
|
|
bool (*dev_has_feat)(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
bool (*dev_feat_enabled)(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
int (*dev_enable_feat)(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
int (*dev_disable_feat)(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
|
|
|
|
|
/* Aux-domain specific attach/detach entries */
|
|
|
|
|
int (*aux_attach_dev)(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
void (*aux_detach_dev)(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
int (*aux_get_pasid)(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
struct iommu_sva *(*sva_bind)(struct device *dev, struct mm_struct *mm,
|
|
|
|
|
void *drvdata);
|
|
|
|
|
void (*sva_unbind)(struct iommu_sva *handle);
|
2020-09-15 19:30:05 +03:00
|
|
|
u32 (*sva_get_pasid)(struct iommu_sva *handle);
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
|
2019-06-03 17:57:49 +03:00
|
|
|
int (*page_response)(struct device *dev,
|
|
|
|
|
struct iommu_fault_event *evt,
|
|
|
|
|
struct iommu_page_response *msg);
|
2019-10-02 22:42:40 +03:00
|
|
|
int (*cache_invalidate)(struct iommu_domain *domain, struct device *dev,
|
|
|
|
|
struct iommu_cache_invalidate_info *inv_info);
|
2019-10-02 22:42:43 +03:00
|
|
|
int (*sva_bind_gpasid)(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev, struct iommu_gpasid_bind_data *data);
|
|
|
|
|
|
2020-09-15 19:30:05 +03:00
|
|
|
int (*sva_unbind_gpasid)(struct device *dev, u32 pasid);
|
2019-06-03 17:57:49 +03:00
|
|
|
|
2020-04-29 16:36:40 +03:00
|
|
|
int (*def_domain_type)(struct device *dev);
|
|
|
|
|
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
unsigned long pgsize_bitmap;
|
2019-12-19 15:03:41 +03:00
|
|
|
struct module *owner;
|
2008-11-26 19:02:33 +03:00
|
|
|
};
|
|
|
|
|
|
2017-02-01 15:23:08 +03:00
|
|
|
/**
|
|
|
|
|
* struct iommu_device - IOMMU core representation of one IOMMU hardware
|
|
|
|
|
* instance
|
|
|
|
|
* @list: Used by the iommu-core to keep a list of registered iommus
|
|
|
|
|
* @ops: iommu-ops for talking to this iommu
|
2017-02-01 18:56:46 +03:00
|
|
|
* @dev: struct device for sysfs handling
|
2017-02-01 15:23:08 +03:00
|
|
|
*/
|
|
|
|
|
struct iommu_device {
|
|
|
|
|
struct list_head list;
|
|
|
|
|
const struct iommu_ops *ops;
|
2017-02-07 20:18:46 +03:00
|
|
|
struct fwnode_handle *fwnode;
|
2017-08-14 18:19:26 +03:00
|
|
|
struct device *dev;
|
2017-02-01 15:23:08 +03:00
|
|
|
};
|
|
|
|
|
|
2019-06-03 17:57:47 +03:00
|
|
|
/**
|
|
|
|
|
* struct iommu_fault_event - Generic fault event
|
|
|
|
|
*
|
|
|
|
|
* Can represent recoverable faults such as a page requests or
|
|
|
|
|
* unrecoverable faults such as DMA or IRQ remapping faults.
|
|
|
|
|
*
|
|
|
|
|
* @fault: fault descriptor
|
2019-06-03 17:57:49 +03:00
|
|
|
* @list: pending fault event list, used for tracking responses
|
2019-06-03 17:57:47 +03:00
|
|
|
*/
|
|
|
|
|
struct iommu_fault_event {
|
|
|
|
|
struct iommu_fault fault;
|
2019-06-03 17:57:49 +03:00
|
|
|
struct list_head list;
|
2019-06-03 17:57:47 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct iommu_fault_param - per-device IOMMU fault data
|
|
|
|
|
* @handler: Callback function to handle IOMMU faults at device level
|
|
|
|
|
* @data: handler private data
|
2019-06-03 17:57:49 +03:00
|
|
|
* @faults: holds the pending faults which needs response
|
|
|
|
|
* @lock: protect pending faults list
|
2019-06-03 17:57:47 +03:00
|
|
|
*/
|
|
|
|
|
struct iommu_fault_param {
|
|
|
|
|
iommu_dev_fault_handler_t handler;
|
|
|
|
|
void *data;
|
2019-06-03 17:57:49 +03:00
|
|
|
struct list_head faults;
|
|
|
|
|
struct mutex lock;
|
2019-06-03 17:57:47 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
2020-03-26 18:08:30 +03:00
|
|
|
* struct dev_iommu - Collection of per-device IOMMU data
|
2019-06-03 17:57:47 +03:00
|
|
|
*
|
|
|
|
|
* @fault_param: IOMMU detected device fault reporting data
|
2021-04-01 18:47:15 +03:00
|
|
|
* @iopf_param: I/O Page Fault queue and data
|
2020-03-26 18:08:31 +03:00
|
|
|
* @fwspec: IOMMU fwspec data
|
2020-04-29 16:36:45 +03:00
|
|
|
* @iommu_dev: IOMMU device this device is linked to
|
2020-03-26 18:08:41 +03:00
|
|
|
* @priv: IOMMU Driver private data
|
2019-06-03 17:57:47 +03:00
|
|
|
*
|
|
|
|
|
* TODO: migrate other per device data pointers under iommu_dev_data, e.g.
|
|
|
|
|
* struct iommu_group *iommu_group;
|
|
|
|
|
*/
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu {
|
2019-06-03 17:57:48 +03:00
|
|
|
struct mutex lock;
|
2020-03-26 18:08:31 +03:00
|
|
|
struct iommu_fault_param *fault_param;
|
2021-04-01 18:47:15 +03:00
|
|
|
struct iopf_device_param *iopf_param;
|
2020-03-26 18:08:31 +03:00
|
|
|
struct iommu_fwspec *fwspec;
|
2020-04-29 16:36:45 +03:00
|
|
|
struct iommu_device *iommu_dev;
|
2020-03-26 18:08:41 +03:00
|
|
|
void *priv;
|
2019-06-03 17:57:47 +03:00
|
|
|
};
|
|
|
|
|
|
2021-04-01 16:56:26 +03:00
|
|
|
int iommu_device_register(struct iommu_device *iommu,
|
|
|
|
|
const struct iommu_ops *ops,
|
|
|
|
|
struct device *hwdev);
|
2017-02-01 15:23:08 +03:00
|
|
|
void iommu_device_unregister(struct iommu_device *iommu);
|
2017-02-01 18:56:46 +03:00
|
|
|
int iommu_device_sysfs_add(struct iommu_device *iommu,
|
|
|
|
|
struct device *parent,
|
|
|
|
|
const struct attribute_group **groups,
|
|
|
|
|
const char *fmt, ...) __printf(4, 5);
|
|
|
|
|
void iommu_device_sysfs_remove(struct iommu_device *iommu);
|
2017-02-01 19:23:22 +03:00
|
|
|
int iommu_device_link(struct iommu_device *iommu, struct device *link);
|
|
|
|
|
void iommu_device_unlink(struct iommu_device *iommu, struct device *link);
|
iommu: use the __iommu_attach_device() directly for deferred attach
Currently, because domain attach allows to be deferred from iommu
driver to device driver, and when iommu initializes, the devices
on the bus will be scanned and the default groups will be allocated.
Due to the above changes, some devices could be added to the same
group as below:
[ 3.859417] pci 0000:01:00.0: Adding to iommu group 16
[ 3.864572] pci 0000:01:00.1: Adding to iommu group 16
[ 3.869738] pci 0000:02:00.0: Adding to iommu group 17
[ 3.874892] pci 0000:02:00.1: Adding to iommu group 17
But when attaching these devices, it doesn't allow that a group has
more than one device, otherwise it will return an error. This conflicts
with the deferred attaching. Unfortunately, it has two devices in the
same group for my side, for example:
[ 9.627014] iommu_group_device_count(): device name[0]:0000:01:00.0
[ 9.633545] iommu_group_device_count(): device name[1]:0000:01:00.1
...
[ 10.255609] iommu_group_device_count(): device name[0]:0000:02:00.0
[ 10.262144] iommu_group_device_count(): device name[1]:0000:02:00.1
Finally, which caused the failure of tg3 driver when tg3 driver calls
the dma_alloc_coherent() to allocate coherent memory in the tg3_test_dma().
[ 9.660310] tg3 0000:01:00.0: DMA engine test failed, aborting
[ 9.754085] tg3: probe of 0000:01:00.0 failed with error -12
[ 9.997512] tg3 0000:01:00.1: DMA engine test failed, aborting
[ 10.043053] tg3: probe of 0000:01:00.1 failed with error -12
[ 10.288905] tg3 0000:02:00.0: DMA engine test failed, aborting
[ 10.334070] tg3: probe of 0000:02:00.0 failed with error -12
[ 10.578303] tg3 0000:02:00.1: DMA engine test failed, aborting
[ 10.622629] tg3: probe of 0000:02:00.1 failed with error -12
In addition, the similar situations also occur in other drivers such
as the bnxt_en driver. That can be reproduced easily in kdump kernel
when SME is active.
Let's move the handling currently in iommu_dma_deferred_attach() into
the iommu core code so that it can call the __iommu_attach_device()
directly instead of the iommu_attach_device(). The external interface
iommu_attach_device() is not suitable for handling this situation.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20210126115337.20068-3-lijiang@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-01-26 14:53:37 +03:00
|
|
|
int iommu_deferred_attach(struct device *dev, struct iommu_domain *domain);
|
2017-02-01 15:23:08 +03:00
|
|
|
|
2017-08-14 18:19:26 +03:00
|
|
|
static inline struct iommu_device *dev_to_iommu_device(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return (struct iommu_device *)dev_get_drvdata(dev);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-02 18:43:48 +03:00
|
|
|
static inline void iommu_iotlb_gather_init(struct iommu_iotlb_gather *gather)
|
|
|
|
|
{
|
|
|
|
|
*gather = (struct iommu_iotlb_gather) {
|
|
|
|
|
.start = ULONG_MAX,
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
#define IOMMU_GROUP_NOTIFY_ADD_DEVICE 1 /* Device added */
|
|
|
|
|
#define IOMMU_GROUP_NOTIFY_DEL_DEVICE 2 /* Pre Device removed */
|
|
|
|
|
#define IOMMU_GROUP_NOTIFY_BIND_DRIVER 3 /* Pre Driver bind */
|
|
|
|
|
#define IOMMU_GROUP_NOTIFY_BOUND_DRIVER 4 /* Post Driver bind */
|
|
|
|
|
#define IOMMU_GROUP_NOTIFY_UNBIND_DRIVER 5 /* Pre Driver unbind */
|
|
|
|
|
#define IOMMU_GROUP_NOTIFY_UNBOUND_DRIVER 6 /* Post Driver unbind */
|
|
|
|
|
|
2014-06-27 11:03:12 +04:00
|
|
|
extern int bus_set_iommu(struct bus_type *bus, const struct iommu_ops *ops);
|
2020-04-29 16:36:51 +03:00
|
|
|
extern int bus_iommu_probe(struct bus_type *bus);
|
2011-09-06 20:46:34 +04:00
|
|
|
extern bool iommu_present(struct bus_type *bus);
|
2014-09-03 20:47:25 +04:00
|
|
|
extern bool iommu_capable(struct bus_type *bus, enum iommu_cap cap);
|
2011-09-06 18:03:26 +04:00
|
|
|
extern struct iommu_domain *iommu_domain_alloc(struct bus_type *bus);
|
2013-03-25 03:23:49 +04:00
|
|
|
extern struct iommu_group *iommu_group_get_by_id(int id);
|
2008-11-26 19:02:33 +03:00
|
|
|
extern void iommu_domain_free(struct iommu_domain *domain);
|
|
|
|
|
extern int iommu_attach_device(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev);
|
|
|
|
|
extern void iommu_detach_device(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev);
|
2020-09-25 19:32:45 +03:00
|
|
|
extern int iommu_uapi_cache_invalidate(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev,
|
2020-09-25 19:32:46 +03:00
|
|
|
void __user *uinfo);
|
|
|
|
|
|
2020-09-25 19:32:45 +03:00
|
|
|
extern int iommu_uapi_sva_bind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev, void __user *udata);
|
2020-09-25 19:32:45 +03:00
|
|
|
extern int iommu_uapi_sva_unbind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev, void __user *udata);
|
2019-10-02 22:42:43 +03:00
|
|
|
extern int iommu_sva_unbind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev, ioasid_t pasid);
|
2015-05-28 19:41:32 +03:00
|
|
|
extern struct iommu_domain *iommu_get_domain_for_dev(struct device *dev);
|
2018-09-12 18:24:12 +03:00
|
|
|
extern struct iommu_domain *iommu_get_dma_domain(struct device *dev);
|
2010-01-08 15:35:09 +03:00
|
|
|
extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
phys_addr_t paddr, size_t size, int prot);
|
2019-09-08 19:56:38 +03:00
|
|
|
extern int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
|
phys_addr_t paddr, size_t size, int prot);
|
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches. After all the drivers
are converted, the temporary default settings will be removed.
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to deal with bytes instead of page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2011-11-10 13:32:26 +04:00
|
|
|
extern size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova,
|
2017-08-23 16:50:04 +03:00
|
|
|
size_t size);
|
|
|
|
|
extern size_t iommu_unmap_fast(struct iommu_domain *domain,
|
2019-07-02 18:43:48 +03:00
|
|
|
unsigned long iova, size_t size,
|
|
|
|
|
struct iommu_iotlb_gather *iotlb_gather);
|
2018-07-30 10:36:26 +03:00
|
|
|
extern size_t iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
|
struct scatterlist *sg,unsigned int nents, int prot);
|
2019-09-08 19:56:38 +03:00
|
|
|
extern size_t iommu_map_sg_atomic(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, struct scatterlist *sg,
|
|
|
|
|
unsigned int nents, int prot);
|
2013-03-28 23:53:58 +04:00
|
|
|
extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova);
|
2011-09-13 23:25:23 +04:00
|
|
|
extern void iommu_set_fault_handler(struct iommu_domain *domain,
|
2012-05-21 21:20:05 +04:00
|
|
|
iommu_fault_handler_t handler, void *token);
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
extern void iommu_get_resv_regions(struct device *dev, struct list_head *list);
|
|
|
|
|
extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
|
2019-12-18 16:42:01 +03:00
|
|
|
extern void generic_iommu_put_resv_regions(struct device *dev,
|
|
|
|
|
struct list_head *list);
|
2019-08-19 16:22:47 +03:00
|
|
|
extern void iommu_set_default_passthrough(bool cmd_line);
|
|
|
|
|
extern void iommu_set_default_translated(bool cmd_line);
|
|
|
|
|
extern bool iommu_default_passthrough(void);
|
2017-01-19 23:57:49 +03:00
|
|
|
extern struct iommu_resv_region *
|
iommu: Disambiguate MSI region types
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 <eric.auger@redhat.com>
CC: Alex Williamson <alex.williamson@redhat.com>
CC: David Woodhouse <dwmw2@infradead.org>
CC: kvm@vger.kernel.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2017-03-16 20:00:16 +03:00
|
|
|
iommu_alloc_resv_region(phys_addr_t start, size_t length, int prot,
|
|
|
|
|
enum iommu_resv_type type);
|
2017-01-19 23:57:51 +03:00
|
|
|
extern int iommu_get_group_resv_regions(struct iommu_group *group,
|
|
|
|
|
struct list_head *head);
|
2015-05-28 19:41:33 +03:00
|
|
|
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
extern int iommu_attach_group(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_group *group);
|
|
|
|
|
extern void iommu_detach_group(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_group *group);
|
|
|
|
|
extern struct iommu_group *iommu_group_alloc(void);
|
|
|
|
|
extern void *iommu_group_get_iommudata(struct iommu_group *group);
|
|
|
|
|
extern void iommu_group_set_iommudata(struct iommu_group *group,
|
|
|
|
|
void *iommu_data,
|
|
|
|
|
void (*release)(void *iommu_data));
|
|
|
|
|
extern int iommu_group_set_name(struct iommu_group *group, const char *name);
|
|
|
|
|
extern int iommu_group_add_device(struct iommu_group *group,
|
|
|
|
|
struct device *dev);
|
|
|
|
|
extern void iommu_group_remove_device(struct device *dev);
|
|
|
|
|
extern int iommu_group_for_each_dev(struct iommu_group *group, void *data,
|
|
|
|
|
int (*fn)(struct device *, void *));
|
|
|
|
|
extern struct iommu_group *iommu_group_get(struct device *dev);
|
2016-11-11 20:59:21 +03:00
|
|
|
extern struct iommu_group *iommu_group_ref_get(struct iommu_group *group);
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
extern void iommu_group_put(struct iommu_group *group);
|
|
|
|
|
extern int iommu_group_register_notifier(struct iommu_group *group,
|
|
|
|
|
struct notifier_block *nb);
|
|
|
|
|
extern int iommu_group_unregister_notifier(struct iommu_group *group,
|
|
|
|
|
struct notifier_block *nb);
|
2019-06-03 17:57:48 +03:00
|
|
|
extern int iommu_register_device_fault_handler(struct device *dev,
|
|
|
|
|
iommu_dev_fault_handler_t handler,
|
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
|
|
extern int iommu_unregister_device_fault_handler(struct device *dev);
|
|
|
|
|
|
|
|
|
|
extern int iommu_report_device_fault(struct device *dev,
|
|
|
|
|
struct iommu_fault_event *evt);
|
2019-06-03 17:57:49 +03:00
|
|
|
extern int iommu_page_response(struct device *dev,
|
|
|
|
|
struct iommu_page_response *msg);
|
2019-06-03 17:57:48 +03:00
|
|
|
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
extern int iommu_group_id(struct iommu_group *group);
|
2015-05-28 19:41:35 +03:00
|
|
|
extern struct iommu_domain *iommu_group_default_domain(struct iommu_group *);
|
2011-09-13 23:25:23 +04:00
|
|
|
|
2021-04-01 18:52:52 +03:00
|
|
|
int iommu_enable_nesting(struct iommu_domain *domain);
|
2021-04-01 18:52:55 +03:00
|
|
|
int iommu_set_pgtable_quirks(struct iommu_domain *domain,
|
|
|
|
|
unsigned long quirks);
|
2011-09-13 23:25:23 +04:00
|
|
|
|
2021-04-01 18:52:54 +03:00
|
|
|
void iommu_set_dma_strict(bool val);
|
|
|
|
|
bool iommu_get_dma_strict(struct iommu_domain *domain);
|
2017-04-26 16:39:28 +03:00
|
|
|
|
|
|
|
|
extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
|
|
|
|
|
unsigned long iova, int flags);
|
2008-11-26 19:02:33 +03:00
|
|
|
|
2020-08-18 00:00:49 +03:00
|
|
|
static inline void iommu_flush_iotlb_all(struct iommu_domain *domain)
|
2017-08-23 16:50:04 +03:00
|
|
|
{
|
|
|
|
|
if (domain->ops->flush_iotlb_all)
|
|
|
|
|
domain->ops->flush_iotlb_all(domain);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 00:00:49 +03:00
|
|
|
static inline void iommu_iotlb_sync(struct iommu_domain *domain,
|
2019-07-02 18:43:48 +03:00
|
|
|
struct iommu_iotlb_gather *iotlb_gather)
|
2017-08-23 16:50:04 +03:00
|
|
|
{
|
|
|
|
|
if (domain->ops->iotlb_sync)
|
2019-07-02 18:44:06 +03:00
|
|
|
domain->ops->iotlb_sync(domain, iotlb_gather);
|
2019-07-02 18:43:48 +03:00
|
|
|
|
|
|
|
|
iommu_iotlb_gather_init(iotlb_gather);
|
2017-08-23 16:50:04 +03:00
|
|
|
}
|
|
|
|
|
|
2019-07-02 18:43:57 +03:00
|
|
|
static inline void iommu_iotlb_gather_add_page(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_iotlb_gather *gather,
|
|
|
|
|
unsigned long iova, size_t size)
|
|
|
|
|
{
|
2021-01-07 15:29:06 +03:00
|
|
|
unsigned long start = iova, end = start + size - 1;
|
2019-07-02 18:43:57 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the new page is disjoint from the current range or is mapped at
|
|
|
|
|
* a different granularity, then sync the TLB so that the gather
|
|
|
|
|
* structure can be rewritten.
|
|
|
|
|
*/
|
|
|
|
|
if (gather->pgsize != size ||
|
2021-03-25 06:38:24 +03:00
|
|
|
end + 1 < gather->start || start > gather->end + 1) {
|
2019-07-02 18:43:57 +03:00
|
|
|
if (gather->pgsize)
|
2020-08-18 00:00:49 +03:00
|
|
|
iommu_iotlb_sync(domain, gather);
|
2019-07-02 18:43:57 +03:00
|
|
|
gather->pgsize = size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (gather->end < end)
|
|
|
|
|
gather->end = end;
|
|
|
|
|
|
|
|
|
|
if (gather->start > start)
|
|
|
|
|
gather->start = start;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-22 00:51:37 +03:00
|
|
|
/* PCI device grouping function */
|
|
|
|
|
extern struct iommu_group *pci_device_group(struct device *dev);
|
2015-10-22 00:51:38 +03:00
|
|
|
/* Generic device grouping function */
|
|
|
|
|
extern struct iommu_group *generic_device_group(struct device *dev);
|
2018-09-10 16:49:18 +03:00
|
|
|
/* FSL-MC device grouping function */
|
|
|
|
|
struct iommu_group *fsl_mc_device_group(struct device *dev);
|
2015-10-22 00:51:37 +03:00
|
|
|
|
2016-09-13 12:54:14 +03:00
|
|
|
/**
|
|
|
|
|
* struct iommu_fwspec - per-device IOMMU instance data
|
|
|
|
|
* @ops: ops for this device's IOMMU
|
|
|
|
|
* @iommu_fwnode: firmware handle for this device's IOMMU
|
2021-04-01 18:47:10 +03:00
|
|
|
* @flags: IOMMU_FWSPEC_* flags
|
2016-09-13 12:54:14 +03:00
|
|
|
* @num_ids: number of associated device IDs
|
|
|
|
|
* @ids: IDs which this device may present to the IOMMU
|
|
|
|
|
*/
|
|
|
|
|
struct iommu_fwspec {
|
|
|
|
|
const struct iommu_ops *ops;
|
|
|
|
|
struct fwnode_handle *iommu_fwnode;
|
2019-04-17 21:24:42 +03:00
|
|
|
u32 flags;
|
2016-09-13 12:54:14 +03:00
|
|
|
unsigned int num_ids;
|
2020-02-13 17:00:21 +03:00
|
|
|
u32 ids[];
|
2016-09-13 12:54:14 +03:00
|
|
|
};
|
|
|
|
|
|
2019-04-17 21:24:42 +03:00
|
|
|
/* ATS is supported */
|
|
|
|
|
#define IOMMU_FWSPEC_PCI_RC_ATS (1 << 0)
|
|
|
|
|
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
/**
|
|
|
|
|
* struct iommu_sva - handle to a device-mm bond
|
|
|
|
|
*/
|
|
|
|
|
struct iommu_sva {
|
|
|
|
|
struct device *dev;
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-13 12:54:14 +03:00
|
|
|
int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
|
|
|
|
|
const struct iommu_ops *ops);
|
|
|
|
|
void iommu_fwspec_free(struct device *dev);
|
|
|
|
|
int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
|
2017-01-31 18:58:42 +03:00
|
|
|
const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode);
|
2016-09-13 12:54:14 +03:00
|
|
|
|
2018-11-28 15:35:24 +03:00
|
|
|
static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev)
|
|
|
|
|
{
|
2020-03-26 18:08:31 +03:00
|
|
|
if (dev->iommu)
|
|
|
|
|
return dev->iommu->fwspec;
|
|
|
|
|
else
|
|
|
|
|
return NULL;
|
2018-11-28 15:35:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dev_iommu_fwspec_set(struct device *dev,
|
|
|
|
|
struct iommu_fwspec *fwspec)
|
|
|
|
|
{
|
2020-03-26 18:08:31 +03:00
|
|
|
dev->iommu->fwspec = fwspec;
|
2018-11-28 15:35:24 +03:00
|
|
|
}
|
|
|
|
|
|
2020-03-26 18:08:33 +03:00
|
|
|
static inline void *dev_iommu_priv_get(struct device *dev)
|
|
|
|
|
{
|
2021-02-02 17:54:19 +03:00
|
|
|
if (dev->iommu)
|
|
|
|
|
return dev->iommu->priv;
|
|
|
|
|
else
|
|
|
|
|
return NULL;
|
2020-03-26 18:08:33 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dev_iommu_priv_set(struct device *dev, void *priv)
|
|
|
|
|
{
|
2020-03-26 18:08:41 +03:00
|
|
|
dev->iommu->priv = priv;
|
2020-03-26 18:08:33 +03:00
|
|
|
}
|
|
|
|
|
|
2018-11-30 12:31:59 +03:00
|
|
|
int iommu_probe_device(struct device *dev);
|
|
|
|
|
void iommu_release_device(struct device *dev);
|
|
|
|
|
|
iommu: Add APIs for multiple domains per device
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the security consideration. With finer-granularity
DMA isolation, subsets of a PCI function can be isolated
from each others by the IOMMU. As a result, there is a
request in software to attach multiple domains to a physical
PCI device. One example of such use model is the Intel
Scalable IOV [1] [2]. The Intel vt-d 3.0 spec [3] introduces
the scalable mode which enables PASID granularity DMA
isolation.
This adds the APIs to support multiple domains per device.
In order to ease the discussions, we call it 'a domain in
auxiliary mode' or simply 'auxiliary domain' when multiple
domains are attached to a physical device.
The APIs include:
* iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
- Detect both IOMMU and PCI endpoint devices supporting
the feature (aux-domain here) without the host driver
dependency.
* iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)
- Check the enabling status of the feature (aux-domain
here). The aux-domain interfaces are available only
if this returns true.
* iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX)
- Enable/disable device specific aux-domain feature.
* iommu_aux_attach_device(domain, dev)
- Attaches @domain to @dev in the auxiliary mode. Multiple
domains could be attached to a single device in the
auxiliary mode with each domain representing an isolated
address space for an assignable subset of the device.
* iommu_aux_detach_device(domain, dev)
- Detach @domain which has been attached to @dev in the
auxiliary mode.
* iommu_aux_get_pasid(domain, dev)
- Return ID used for finer-granularity DMA translation.
For the Intel Scalable IOV usage model, this will be
a PASID. The device which supports Scalable IOV needs
to write this ID to the device register so that DMA
requests could be tagged with a right PASID prefix.
This has been updated with the latest proposal from Joerg
posted here [5].
Many people involved in discussions of this design.
Kevin Tian <kevin.tian@intel.com>
Liu Yi L <yi.l.liu@intel.com>
Ashok Raj <ashok.raj@intel.com>
Sanjay Kumar <sanjay.k.kumar@intel.com>
Jacob Pan <jacob.jun.pan@linux.intel.com>
Alex Williamson <alex.williamson@redhat.com>
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Joerg Roedel <joro@8bytes.org>
and some discussions can be found here [4] [5].
[1] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
[2] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
[3] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
[4] https://lkml.org/lkml/2018/7/26/4
[5] https://www.spinics.net/lists/iommu/msg31874.html
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Suggested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-03-25 04:30:28 +03:00
|
|
|
int iommu_dev_enable_feature(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
int iommu_dev_disable_feature(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
bool iommu_dev_feature_enabled(struct device *dev, enum iommu_dev_features f);
|
|
|
|
|
int iommu_aux_attach_device(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
void iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
int iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev);
|
|
|
|
|
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
|
|
|
|
|
struct mm_struct *mm,
|
|
|
|
|
void *drvdata);
|
|
|
|
|
void iommu_sva_unbind_device(struct iommu_sva *handle);
|
2020-09-15 19:30:05 +03:00
|
|
|
u32 iommu_sva_get_pasid(struct iommu_sva *handle);
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
|
2008-11-26 19:02:33 +03:00
|
|
|
#else /* CONFIG_IOMMU_API */
|
|
|
|
|
|
2011-09-06 18:48:40 +04:00
|
|
|
struct iommu_ops {};
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
struct iommu_group {};
|
2016-09-13 12:54:14 +03:00
|
|
|
struct iommu_fwspec {};
|
2017-02-01 15:23:08 +03:00
|
|
|
struct iommu_device {};
|
2019-06-03 17:57:47 +03:00
|
|
|
struct iommu_fault_param {};
|
2019-07-02 18:43:48 +03:00
|
|
|
struct iommu_iotlb_gather {};
|
2008-11-26 19:02:33 +03:00
|
|
|
|
2011-09-06 20:46:34 +04:00
|
|
|
static inline bool iommu_present(struct bus_type *bus)
|
2008-11-26 19:02:33 +03:00
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-03 20:47:25 +04:00
|
|
|
static inline bool iommu_capable(struct bus_type *bus, enum iommu_cap cap)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-06 18:03:26 +04:00
|
|
|
static inline struct iommu_domain *iommu_domain_alloc(struct bus_type *bus)
|
2008-11-26 19:02:33 +03:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-21 10:41:14 +04:00
|
|
|
static inline struct iommu_group *iommu_group_get_by_id(int id)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2008-11-26 19:02:33 +03:00
|
|
|
static inline void iommu_domain_free(struct iommu_domain *domain)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int iommu_attach_device(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void iommu_detach_device(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-28 19:41:32 +03:00
|
|
|
static inline struct iommu_domain *iommu_get_domain_for_dev(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-08 15:35:09 +03:00
|
|
|
static inline int iommu_map(struct iommu_domain *domain, unsigned long iova,
|
2017-07-05 20:27:53 +03:00
|
|
|
phys_addr_t paddr, size_t size, int prot)
|
2010-01-08 15:35:09 +03:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-08 19:56:38 +03:00
|
|
|
static inline int iommu_map_atomic(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, phys_addr_t paddr,
|
|
|
|
|
size_t size, int prot)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-05 13:45:53 +03:00
|
|
|
static inline size_t iommu_unmap(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, size_t size)
|
2010-01-08 15:35:09 +03:00
|
|
|
{
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
2010-01-08 15:35:09 +03:00
|
|
|
}
|
|
|
|
|
|
2018-02-05 13:45:53 +03:00
|
|
|
static inline size_t iommu_unmap_fast(struct iommu_domain *domain,
|
2019-07-02 18:43:48 +03:00
|
|
|
unsigned long iova, int gfp_order,
|
|
|
|
|
struct iommu_iotlb_gather *iotlb_gather)
|
2010-01-08 15:35:09 +03:00
|
|
|
{
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
2010-01-08 15:35:09 +03:00
|
|
|
}
|
|
|
|
|
|
2014-10-25 20:55:16 +04:00
|
|
|
static inline size_t iommu_map_sg(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, struct scatterlist *sg,
|
|
|
|
|
unsigned int nents, int prot)
|
|
|
|
|
{
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
2014-10-25 20:55:16 +04:00
|
|
|
}
|
|
|
|
|
|
2019-09-08 19:56:38 +03:00
|
|
|
static inline size_t iommu_map_sg_atomic(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, struct scatterlist *sg,
|
|
|
|
|
unsigned int nents, int prot)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 00:00:49 +03:00
|
|
|
static inline void iommu_flush_iotlb_all(struct iommu_domain *domain)
|
2017-08-23 16:50:04 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 00:00:49 +03:00
|
|
|
static inline void iommu_iotlb_sync(struct iommu_domain *domain,
|
2019-07-02 18:43:48 +03:00
|
|
|
struct iommu_iotlb_gather *iotlb_gather)
|
2017-08-23 16:50:04 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-28 23:53:58 +04:00
|
|
|
static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
|
2008-11-26 19:02:33 +03:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-13 23:25:23 +04:00
|
|
|
static inline void iommu_set_fault_handler(struct iommu_domain *domain,
|
2012-05-21 21:20:05 +04:00
|
|
|
iommu_fault_handler_t handler, void *token)
|
2011-09-13 23:25:23 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
static inline void iommu_get_resv_regions(struct device *dev,
|
2015-05-28 19:41:33 +03:00
|
|
|
struct list_head *list)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
static inline void iommu_put_resv_regions(struct device *dev,
|
2015-05-28 19:41:33 +03:00
|
|
|
struct list_head *list)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 23:57:51 +03:00
|
|
|
static inline int iommu_get_group_resv_regions(struct iommu_group *group,
|
|
|
|
|
struct list_head *head)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-19 16:22:47 +03:00
|
|
|
static inline void iommu_set_default_passthrough(bool cmd_line)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void iommu_set_default_translated(bool cmd_line)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool iommu_default_passthrough(void)
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_attach_group(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_group *group)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline void iommu_detach_group(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_group *group)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline struct iommu_group *iommu_group_alloc(void)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline void *iommu_group_get_iommudata(struct iommu_group *group)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline void iommu_group_set_iommudata(struct iommu_group *group,
|
|
|
|
|
void *iommu_data,
|
|
|
|
|
void (*release)(void *iommu_data))
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_set_name(struct iommu_group *group,
|
|
|
|
|
const char *name)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_add_device(struct iommu_group *group,
|
|
|
|
|
struct device *dev)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline void iommu_group_remove_device(struct device *dev)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_for_each_dev(struct iommu_group *group,
|
|
|
|
|
void *data,
|
|
|
|
|
int (*fn)(struct device *, void *))
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline struct iommu_group *iommu_group_get(struct device *dev)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline void iommu_group_put(struct iommu_group *group)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_register_notifier(struct iommu_group *group,
|
|
|
|
|
struct notifier_block *nb)
|
2011-10-21 23:56:05 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_unregister_notifier(struct iommu_group *group,
|
|
|
|
|
struct notifier_block *nb)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-03 17:57:48 +03:00
|
|
|
static inline
|
|
|
|
|
int iommu_register_device_fault_handler(struct device *dev,
|
|
|
|
|
iommu_dev_fault_handler_t handler,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int iommu_unregister_device_fault_handler(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-03 17:57:49 +03:00
|
|
|
static inline int iommu_page_response(struct device *dev,
|
|
|
|
|
struct iommu_page_response *msg)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-25 07:23:25 +04:00
|
|
|
static inline int iommu_group_id(struct iommu_group *group)
|
iommu: IOMMU Groups
IOMMU device groups are currently a rather vague associative notion
with assembly required by the user or user level driver provider to
do anything useful. This patch intends to grow the IOMMU group concept
into something a bit more consumable.
To do this, we first create an object representing the group, struct
iommu_group. This structure is allocated (iommu_group_alloc) and
filled (iommu_group_add_device) by the iommu driver. The iommu driver
is free to add devices to the group using it's own set of policies.
This allows inclusion of devices based on physical hardware or topology
limitations of the platform, as well as soft requirements, such as
multi-function trust levels or peer-to-peer protection of the
interconnects. Each device may only belong to a single iommu group,
which is linked from struct device.iommu_group. IOMMU groups are
maintained using kobject reference counting, allowing for automatic
removal of empty, unreferenced groups. It is the responsibility of
the iommu driver to remove devices from the group
(iommu_group_remove_device).
IOMMU groups also include a userspace representation in sysfs under
/sys/kernel/iommu_groups. When allocated, each group is given a
dynamically assign ID (int). The ID is managed by the core IOMMU group
code to support multiple heterogeneous iommu drivers, which could
potentially collide in group naming/numbering. This also keeps group
IDs to small, easily managed values. A directory is created under
/sys/kernel/iommu_groups for each group. A further subdirectory named
"devices" contains links to each device within the group. The iommu_group
file in the device's sysfs directory, which formerly contained a group
number when read, is now a link to the iommu group. Example:
$ ls -l /sys/kernel/iommu_groups/26/devices/
total 0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
../../../../devices/pci0000:00/0000:00:1e.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
$ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
[truncating perms/owner/timestamp]
/sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
../../../../kernel/iommu_groups/26
/sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
../../../../kernel/iommu_groups/26
Groups also include several exported functions for use by user level
driver providers, for example VFIO. These include:
iommu_group_get(): Acquires a reference to a group from a device
iommu_group_put(): Releases reference
iommu_group_for_each_dev(): Iterates over group devices using callback
iommu_group_[un]register_notifier(): Allows notification of device add
and remove operations relevant to the group
iommu_group_id(): Return the group number
This patch also extends the IOMMU API to allow attaching groups to
domains. This is currently a simple wrapper for iterating through
devices within a group, but it's expected that the IOMMU API may
eventually make groups a more integral part of domains.
Groups intentionally do not try to manage group ownership. A user
level driver provider must independently acquire ownership for each
device within a group before making use of the group as a whole.
This may change in the future if group usage becomes more pervasive
across both DMA and IOMMU ops.
Groups intentionally do not provide a mechanism for driver locking
or otherwise manipulating driver matching/probing of devices within
the group. Such interfaces are generic to devices and beyond the
scope of IOMMU groups. If implemented, user level providers have
ready access via iommu_group_for_each_dev and group notifiers.
iommu_device_group() is removed here as it has no users. The
replacement is:
group = iommu_group_get(dev);
id = iommu_group_id(group);
iommu_group_put(group);
AMD-Vi & Intel VT-d support re-added in following patches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-31 00:18:53 +04:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2011-10-21 23:56:05 +04:00
|
|
|
|
2021-04-01 18:52:55 +03:00
|
|
|
static inline int iommu_set_pgtable_quirks(struct iommu_domain *domain,
|
|
|
|
|
unsigned long quirks)
|
2012-01-26 22:40:52 +04:00
|
|
|
{
|
2021-04-01 18:52:55 +03:00
|
|
|
return 0;
|
2012-01-26 22:40:52 +04:00
|
|
|
}
|
|
|
|
|
|
2021-04-01 16:56:26 +03:00
|
|
|
static inline int iommu_device_register(struct iommu_device *iommu,
|
|
|
|
|
const struct iommu_ops *ops,
|
|
|
|
|
struct device *hwdev)
|
2014-06-13 02:12:24 +04:00
|
|
|
{
|
2017-02-01 18:56:46 +03:00
|
|
|
return -ENODEV;
|
2014-06-13 02:12:24 +04:00
|
|
|
}
|
|
|
|
|
|
2017-08-14 18:19:26 +03:00
|
|
|
static inline struct iommu_device *dev_to_iommu_device(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-02 18:43:48 +03:00
|
|
|
static inline void iommu_iotlb_gather_init(struct iommu_iotlb_gather *gather)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-02 18:43:57 +03:00
|
|
|
static inline void iommu_iotlb_gather_add_page(struct iommu_domain *domain,
|
|
|
|
|
struct iommu_iotlb_gather *gather,
|
|
|
|
|
unsigned long iova, size_t size)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-01 18:56:46 +03:00
|
|
|
static inline void iommu_device_unregister(struct iommu_device *iommu)
|
2014-06-13 02:12:24 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-01 18:56:46 +03:00
|
|
|
static inline int iommu_device_sysfs_add(struct iommu_device *iommu,
|
|
|
|
|
struct device *parent,
|
|
|
|
|
const struct attribute_group **groups,
|
|
|
|
|
const char *fmt, ...)
|
2017-02-01 15:23:08 +03:00
|
|
|
{
|
2017-02-01 18:56:46 +03:00
|
|
|
return -ENODEV;
|
2017-02-01 15:23:08 +03:00
|
|
|
}
|
|
|
|
|
|
2017-02-01 18:56:46 +03:00
|
|
|
static inline void iommu_device_sysfs_remove(struct iommu_device *iommu)
|
2014-06-13 02:12:24 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-08 00:31:36 +04:00
|
|
|
static inline int iommu_device_link(struct device *dev, struct device *link)
|
2014-06-13 02:12:24 +04:00
|
|
|
{
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-08 00:31:36 +04:00
|
|
|
static inline void iommu_device_unlink(struct device *dev, struct device *link)
|
2014-06-13 02:12:24 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-13 12:54:14 +03:00
|
|
|
static inline int iommu_fwspec_init(struct device *dev,
|
|
|
|
|
struct fwnode_handle *iommu_fwnode,
|
|
|
|
|
const struct iommu_ops *ops)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void iommu_fwspec_free(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
|
|
|
|
|
int num_ids)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-21 13:01:36 +03:00
|
|
|
static inline
|
2017-01-31 18:58:42 +03:00
|
|
|
const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
|
2016-11-21 13:01:36 +03:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
iommu: Add APIs for multiple domains per device
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the security consideration. With finer-granularity
DMA isolation, subsets of a PCI function can be isolated
from each others by the IOMMU. As a result, there is a
request in software to attach multiple domains to a physical
PCI device. One example of such use model is the Intel
Scalable IOV [1] [2]. The Intel vt-d 3.0 spec [3] introduces
the scalable mode which enables PASID granularity DMA
isolation.
This adds the APIs to support multiple domains per device.
In order to ease the discussions, we call it 'a domain in
auxiliary mode' or simply 'auxiliary domain' when multiple
domains are attached to a physical device.
The APIs include:
* iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)
- Detect both IOMMU and PCI endpoint devices supporting
the feature (aux-domain here) without the host driver
dependency.
* iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)
- Check the enabling status of the feature (aux-domain
here). The aux-domain interfaces are available only
if this returns true.
* iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX)
- Enable/disable device specific aux-domain feature.
* iommu_aux_attach_device(domain, dev)
- Attaches @domain to @dev in the auxiliary mode. Multiple
domains could be attached to a single device in the
auxiliary mode with each domain representing an isolated
address space for an assignable subset of the device.
* iommu_aux_detach_device(domain, dev)
- Detach @domain which has been attached to @dev in the
auxiliary mode.
* iommu_aux_get_pasid(domain, dev)
- Return ID used for finer-granularity DMA translation.
For the Intel Scalable IOV usage model, this will be
a PASID. The device which supports Scalable IOV needs
to write this ID to the device register so that DMA
requests could be tagged with a right PASID prefix.
This has been updated with the latest proposal from Joerg
posted here [5].
Many people involved in discussions of this design.
Kevin Tian <kevin.tian@intel.com>
Liu Yi L <yi.l.liu@intel.com>
Ashok Raj <ashok.raj@intel.com>
Sanjay Kumar <sanjay.k.kumar@intel.com>
Jacob Pan <jacob.jun.pan@linux.intel.com>
Alex Williamson <alex.williamson@redhat.com>
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Joerg Roedel <joro@8bytes.org>
and some discussions can be found here [4] [5].
[1] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
[2] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
[3] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
[4] https://lkml.org/lkml/2018/7/26/4
[5] https://www.spinics.net/lists/iommu/msg31874.html
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Suggested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-03-25 04:30:28 +03:00
|
|
|
static inline bool
|
|
|
|
|
iommu_dev_feature_enabled(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
iommu_dev_enable_feature(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
iommu_dev_disable_feature(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
iommu_aux_attach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
static inline struct iommu_sva *
|
|
|
|
|
iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void iommu_sva_unbind_device(struct iommu_sva *handle)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-15 19:30:05 +03:00
|
|
|
static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
|
iommu: Bind process address spaces to devices
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address space), which can be retrieved with
iommu_sva_get_pasid(). When programming DMA addresses, device drivers
include this PASID in a device-specific manner, to let the device access
the given address space. Since the process memory may be paged out, device
and IOMMU must support I/O page faults (e.g. PCI PRI).
Using iommu_sva_set_ops(), device drivers provide an mm_exit() callback
that is called by the IOMMU driver if the process exits before the device
driver called unbind(). In mm_exit(), device driver should disable DMA
from the given context, so that the core IOMMU can reallocate the PASID.
Whether the process exited or nor, the device driver should always release
the handle with unbind().
To use these functions, device driver must first enable the
IOMMU_DEV_FEAT_SVA device feature with iommu_dev_enable_feature().
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-04-10 18:15:16 +03:00
|
|
|
{
|
|
|
|
|
return IOMMU_PASID_INVALID;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-02 22:42:40 +03:00
|
|
|
static inline int
|
2020-09-25 19:32:46 +03:00
|
|
|
iommu_uapi_cache_invalidate(struct iommu_domain *domain,
|
|
|
|
|
struct device *dev,
|
|
|
|
|
struct iommu_cache_invalidate_info *inv_info)
|
2019-10-02 22:42:40 +03:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2020-09-25 19:32:45 +03:00
|
|
|
|
|
|
|
|
static inline int iommu_uapi_sva_bind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev, void __user *udata)
|
2019-10-02 22:42:43 +03:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-25 19:32:45 +03:00
|
|
|
static inline int iommu_uapi_sva_unbind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev, void __user *udata)
|
2019-10-02 22:42:43 +03:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int iommu_sva_unbind_gpasid(struct iommu_domain *domain,
|
2020-09-25 19:32:46 +03:00
|
|
|
struct device *dev,
|
|
|
|
|
ioasid_t pasid)
|
2019-10-02 22:42:43 +03:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2019-10-02 22:42:40 +03:00
|
|
|
|
2020-03-26 18:08:26 +03:00
|
|
|
static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2008-11-26 19:02:33 +03:00
|
|
|
#endif /* CONFIG_IOMMU_API */
|
|
|
|
|
|
2020-06-30 11:17:56 +03:00
|
|
|
/**
|
|
|
|
|
* iommu_map_sgtable - Map the given buffer to the IOMMU domain
|
|
|
|
|
* @domain: The IOMMU domain to perform the mapping
|
|
|
|
|
* @iova: The start address to map the buffer
|
|
|
|
|
* @sgt: The sg_table object describing the buffer
|
|
|
|
|
* @prot: IOMMU protection bits
|
|
|
|
|
*
|
|
|
|
|
* Creates a mapping at @iova for the buffer described by a scatterlist
|
|
|
|
|
* stored in the given sg_table object in the provided IOMMU domain.
|
|
|
|
|
*/
|
|
|
|
|
static inline size_t iommu_map_sgtable(struct iommu_domain *domain,
|
|
|
|
|
unsigned long iova, struct sg_table *sgt, int prot)
|
|
|
|
|
{
|
|
|
|
|
return iommu_map_sg(domain, iova, sgt->sgl, sgt->orig_nents, prot);
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-13 00:41:21 +03:00
|
|
|
#ifdef CONFIG_IOMMU_DEBUGFS
|
|
|
|
|
extern struct dentry *iommu_debugfs_dir;
|
|
|
|
|
void iommu_debugfs_setup(void);
|
|
|
|
|
#else
|
|
|
|
|
static inline void iommu_debugfs_setup(void) {}
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-11-26 19:02:33 +03:00
|
|
|
#endif /* __LINUX_IOMMU_H */
|
