2019-05-30 02:57:47 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2008-11-26 19:21:24 +03:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2007-2008 Advanced Micro Devices, Inc.
|
2015-02-04 18:12:55 +03:00
|
|
|
* Author: Joerg Roedel <jroedel@suse.de>
|
2008-11-26 19:21:24 +03:00
|
|
|
*/
|
|
|
|
|
2015-05-28 19:41:24 +03:00
|
|
|
#define pr_fmt(fmt) "iommu: " fmt
|
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
|
|
|
|
2011-09-06 18:03:26 +04:00
|
|
|
#include <linux/device.h>
|
2021-08-11 15:21:15 +03:00
|
|
|
#include <linux/dma-iommu.h>
|
2011-09-02 21:32:32 +04:00
|
|
|
#include <linux/kernel.h>
|
2021-06-16 16:38:46 +03:00
|
|
|
#include <linux/bits.h>
|
2008-11-26 19:21:24 +03:00
|
|
|
#include <linux/bug.h>
|
|
|
|
#include <linux/types.h>
|
2018-12-01 22:19:09 +03:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/export.h>
|
2009-05-07 03:03:07 +04:00
|
|
|
#include <linux/slab.h>
|
2008-11-26 19:21:24 +03:00
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/iommu.h>
|
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
|
|
|
#include <linux/idr.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/err.h>
|
2014-07-03 19:51:18 +04:00
|
|
|
#include <linux/pci.h>
|
2014-09-19 20:03:06 +04:00
|
|
|
#include <linux/bitops.h>
|
2016-09-13 12:54:14 +03:00
|
|
|
#include <linux/property.h>
|
2018-09-10 16:49:18 +03:00
|
|
|
#include <linux/fsl/mc.h>
|
2019-12-19 15:03:41 +03:00
|
|
|
#include <linux/module.h>
|
2021-09-09 01:58:39 +03:00
|
|
|
#include <linux/cc_platform.h>
|
2013-08-15 21:59:23 +04:00
|
|
|
#include <trace/events/iommu.h>
|
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
|
|
|
|
|
|
|
static struct kset *iommu_group_kset;
|
2016-06-28 21:38:36 +03:00
|
|
|
static DEFINE_IDA(iommu_group_ida);
|
2019-08-19 16:22:54 +03:00
|
|
|
|
|
|
|
static unsigned int iommu_def_domain_type __read_mostly;
|
2021-08-11 15:21:37 +03:00
|
|
|
static bool iommu_dma_strict __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_DMA_STRICT);
|
2019-08-19 16:22:46 +03:00
|
|
|
static u32 iommu_cmd_line __read_mostly;
|
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 {
|
|
|
|
struct kobject kobj;
|
|
|
|
struct kobject *devices_kobj;
|
|
|
|
struct list_head devices;
|
|
|
|
struct mutex mutex;
|
|
|
|
struct blocking_notifier_head notifier;
|
|
|
|
void *iommu_data;
|
|
|
|
void (*iommu_data_release)(void *iommu_data);
|
|
|
|
char *name;
|
|
|
|
int id;
|
2015-05-28 19:41:29 +03:00
|
|
|
struct iommu_domain *default_domain;
|
2015-05-28 19:41:31 +03:00
|
|
|
struct iommu_domain *domain;
|
2020-04-29 16:36:47 +03:00
|
|
|
struct list_head entry;
|
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-02-01 14:19:46 +03:00
|
|
|
struct group_device {
|
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 list_head list;
|
|
|
|
struct device *dev;
|
|
|
|
char *name;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct iommu_group_attribute {
|
|
|
|
struct attribute attr;
|
|
|
|
ssize_t (*show)(struct iommu_group *group, char *buf);
|
|
|
|
ssize_t (*store)(struct iommu_group *group,
|
|
|
|
const char *buf, size_t count);
|
|
|
|
};
|
|
|
|
|
2017-01-19 23:57:52 +03:00
|
|
|
static const char * const iommu_group_resv_type_string[] = {
|
2019-06-03 09:53:35 +03:00
|
|
|
[IOMMU_RESV_DIRECT] = "direct",
|
|
|
|
[IOMMU_RESV_DIRECT_RELAXABLE] = "direct-relaxable",
|
|
|
|
[IOMMU_RESV_RESERVED] = "reserved",
|
|
|
|
[IOMMU_RESV_MSI] = "msi",
|
|
|
|
[IOMMU_RESV_SW_MSI] = "msi",
|
2017-01-19 23:57:52 +03:00
|
|
|
};
|
|
|
|
|
2019-08-19 16:22:46 +03:00
|
|
|
#define IOMMU_CMD_LINE_DMA_API BIT(0)
|
2021-04-01 18:52:54 +03:00
|
|
|
#define IOMMU_CMD_LINE_STRICT BIT(1)
|
2019-08-19 16:22:46 +03:00
|
|
|
|
2020-05-25 16:01:22 +03:00
|
|
|
static int iommu_alloc_default_domain(struct iommu_group *group,
|
|
|
|
struct device *dev);
|
2020-04-29 16:36:46 +03:00
|
|
|
static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
|
|
|
|
unsigned type);
|
|
|
|
static int __iommu_attach_device(struct iommu_domain *domain,
|
|
|
|
struct device *dev);
|
|
|
|
static int __iommu_attach_group(struct iommu_domain *domain,
|
|
|
|
struct iommu_group *group);
|
|
|
|
static void __iommu_detach_group(struct iommu_domain *domain,
|
|
|
|
struct iommu_group *group);
|
2020-04-29 16:36:50 +03:00
|
|
|
static int iommu_create_device_direct_mappings(struct iommu_group *group,
|
|
|
|
struct device *dev);
|
2020-04-29 16:37:12 +03:00
|
|
|
static struct iommu_group *iommu_group_get_for_dev(struct device *dev);
|
2020-11-24 16:06:02 +03:00
|
|
|
static ssize_t iommu_group_store_type(struct iommu_group *group,
|
|
|
|
const char *buf, size_t count);
|
2020-04-29 16:36:46 +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
|
|
|
#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \
|
|
|
|
struct iommu_group_attribute iommu_group_attr_##_name = \
|
|
|
|
__ATTR(_name, _mode, _show, _store)
|
2008-11-26 19:21:24 +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
|
|
|
#define to_iommu_group_attr(_attr) \
|
|
|
|
container_of(_attr, struct iommu_group_attribute, attr)
|
|
|
|
#define to_iommu_group(_kobj) \
|
|
|
|
container_of(_kobj, struct iommu_group, kobj)
|
2008-11-26 19:21:24 +03:00
|
|
|
|
2017-02-01 15:23:08 +03:00
|
|
|
static LIST_HEAD(iommu_device_list);
|
|
|
|
static DEFINE_SPINLOCK(iommu_device_lock);
|
|
|
|
|
2019-08-19 16:22:53 +03:00
|
|
|
/*
|
|
|
|
* Use a function instead of an array here because the domain-type is a
|
|
|
|
* bit-field, so an array would waste memory.
|
|
|
|
*/
|
|
|
|
static const char *iommu_domain_type_str(unsigned int t)
|
|
|
|
{
|
|
|
|
switch (t) {
|
|
|
|
case IOMMU_DOMAIN_BLOCKED:
|
|
|
|
return "Blocked";
|
|
|
|
case IOMMU_DOMAIN_IDENTITY:
|
|
|
|
return "Passthrough";
|
|
|
|
case IOMMU_DOMAIN_UNMANAGED:
|
|
|
|
return "Unmanaged";
|
|
|
|
case IOMMU_DOMAIN_DMA:
|
2021-08-11 15:21:30 +03:00
|
|
|
case IOMMU_DOMAIN_DMA_FQ:
|
2019-08-19 16:22:53 +03:00
|
|
|
return "Translated";
|
|
|
|
default:
|
|
|
|
return "Unknown";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init iommu_subsys_init(void)
|
|
|
|
{
|
2021-04-01 18:52:53 +03:00
|
|
|
if (!(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API)) {
|
2019-08-19 16:22:54 +03:00
|
|
|
if (IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH))
|
|
|
|
iommu_set_default_passthrough(false);
|
|
|
|
else
|
|
|
|
iommu_set_default_translated(false);
|
2019-08-19 16:22:55 +03:00
|
|
|
|
2021-09-09 01:58:39 +03:00
|
|
|
if (iommu_default_passthrough() && cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
|
2019-09-03 16:15:44 +03:00
|
|
|
pr_info("Memory encryption detected - Disabling default IOMMU Passthrough\n");
|
2019-08-19 16:22:55 +03:00
|
|
|
iommu_set_default_translated(false);
|
|
|
|
}
|
2019-08-19 16:22:54 +03:00
|
|
|
}
|
|
|
|
|
2021-08-11 15:21:34 +03:00
|
|
|
if (!iommu_default_passthrough() && !iommu_dma_strict)
|
|
|
|
iommu_def_domain_type = IOMMU_DOMAIN_DMA_FQ;
|
|
|
|
|
2019-08-19 16:22:54 +03:00
|
|
|
pr_info("Default domain type: %s %s\n",
|
|
|
|
iommu_domain_type_str(iommu_def_domain_type),
|
2021-04-01 18:52:53 +03:00
|
|
|
(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API) ?
|
|
|
|
"(set via kernel command line)" : "");
|
2019-08-19 16:22:53 +03:00
|
|
|
|
2021-08-11 15:21:36 +03:00
|
|
|
if (!iommu_default_passthrough())
|
|
|
|
pr_info("DMA domain TLB invalidation policy: %s mode %s\n",
|
|
|
|
iommu_dma_strict ? "strict" : "lazy",
|
|
|
|
(iommu_cmd_line & IOMMU_CMD_LINE_STRICT) ?
|
|
|
|
"(set via kernel command line)" : "");
|
2021-07-12 14:12:16 +03:00
|
|
|
|
2019-08-19 16:22:53 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(iommu_subsys_init);
|
|
|
|
|
2021-04-01 16:56:26 +03:00
|
|
|
/**
|
|
|
|
* iommu_device_register() - Register an IOMMU hardware instance
|
|
|
|
* @iommu: IOMMU handle for the instance
|
|
|
|
* @ops: IOMMU ops to associate with the instance
|
|
|
|
* @hwdev: (optional) actual instance device, used for fwnode lookup
|
|
|
|
*
|
|
|
|
* Return: 0 on success, or an error.
|
|
|
|
*/
|
|
|
|
int iommu_device_register(struct iommu_device *iommu,
|
|
|
|
const struct iommu_ops *ops, struct device *hwdev)
|
2017-02-01 15:23:08 +03:00
|
|
|
{
|
2021-04-01 16:56:26 +03:00
|
|
|
/* We need to be able to take module references appropriately */
|
|
|
|
if (WARN_ON(is_module_address((unsigned long)ops) && !ops->owner))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
iommu->ops = ops;
|
|
|
|
if (hwdev)
|
|
|
|
iommu->fwnode = hwdev->fwnode;
|
|
|
|
|
2017-02-01 15:23:08 +03:00
|
|
|
spin_lock(&iommu_device_lock);
|
|
|
|
list_add_tail(&iommu->list, &iommu_device_list);
|
|
|
|
spin_unlock(&iommu_device_lock);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_device_register);
|
2017-02-01 15:23:08 +03:00
|
|
|
|
|
|
|
void iommu_device_unregister(struct iommu_device *iommu)
|
|
|
|
{
|
|
|
|
spin_lock(&iommu_device_lock);
|
|
|
|
list_del(&iommu->list);
|
|
|
|
spin_unlock(&iommu_device_lock);
|
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_device_unregister);
|
2017-02-01 15:23:08 +03:00
|
|
|
|
2020-03-26 18:08:30 +03:00
|
|
|
static struct dev_iommu *dev_iommu_get(struct device *dev)
|
2019-06-03 17:57:48 +03:00
|
|
|
{
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu *param = dev->iommu;
|
2019-06-03 17:57:48 +03:00
|
|
|
|
|
|
|
if (param)
|
|
|
|
return param;
|
|
|
|
|
|
|
|
param = kzalloc(sizeof(*param), GFP_KERNEL);
|
|
|
|
if (!param)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mutex_init(¶m->lock);
|
2020-03-26 18:08:30 +03:00
|
|
|
dev->iommu = param;
|
2019-06-03 17:57:48 +03:00
|
|
|
return param;
|
|
|
|
}
|
|
|
|
|
2020-03-26 18:08:30 +03:00
|
|
|
static void dev_iommu_free(struct device *dev)
|
2019-06-03 17:57:48 +03:00
|
|
|
{
|
2020-04-02 17:37:49 +03:00
|
|
|
iommu_fwspec_free(dev);
|
2020-03-26 18:08:30 +03:00
|
|
|
kfree(dev->iommu);
|
|
|
|
dev->iommu = NULL;
|
2019-06-03 17:57:48 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:47 +03:00
|
|
|
static int __iommu_probe_device(struct device *dev, struct list_head *group_list)
|
2018-11-30 12:31:59 +03:00
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
2020-04-29 16:36:45 +03:00
|
|
|
struct iommu_device *iommu_dev;
|
|
|
|
struct iommu_group *group;
|
2019-06-03 17:57:48 +03:00
|
|
|
int ret;
|
2018-11-30 12:31:59 +03:00
|
|
|
|
2019-06-03 17:57:48 +03:00
|
|
|
if (!ops)
|
2020-05-11 19:10:00 +03:00
|
|
|
return -ENODEV;
|
2018-11-30 12:31:59 +03:00
|
|
|
|
2020-03-26 18:08:30 +03:00
|
|
|
if (!dev_iommu_get(dev))
|
2019-06-03 17:57:48 +03:00
|
|
|
return -ENOMEM;
|
2018-11-30 12:31:59 +03:00
|
|
|
|
2019-12-19 15:03:41 +03:00
|
|
|
if (!try_module_get(ops->owner)) {
|
|
|
|
ret = -EINVAL;
|
2020-04-29 16:37:11 +03:00
|
|
|
goto err_free;
|
2019-12-19 15:03:41 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:45 +03:00
|
|
|
iommu_dev = ops->probe_device(dev);
|
2020-04-29 16:37:11 +03:00
|
|
|
if (IS_ERR(iommu_dev)) {
|
|
|
|
ret = PTR_ERR(iommu_dev);
|
|
|
|
goto out_module_put;
|
|
|
|
}
|
2020-04-29 16:36:45 +03:00
|
|
|
|
|
|
|
dev->iommu->iommu_dev = iommu_dev;
|
|
|
|
|
|
|
|
group = iommu_group_get_for_dev(dev);
|
2020-04-29 16:36:49 +03:00
|
|
|
if (IS_ERR(group)) {
|
2020-04-29 16:36:45 +03:00
|
|
|
ret = PTR_ERR(group);
|
|
|
|
goto out_release;
|
|
|
|
}
|
|
|
|
iommu_group_put(group);
|
|
|
|
|
2020-04-29 16:36:47 +03:00
|
|
|
if (group_list && !group->default_domain && list_empty(&group->entry))
|
|
|
|
list_add_tail(&group->entry, group_list);
|
|
|
|
|
2020-04-29 16:36:45 +03:00
|
|
|
iommu_device_link(iommu_dev, dev);
|
2019-12-19 15:03:41 +03:00
|
|
|
|
|
|
|
return 0;
|
2018-12-20 12:02:20 +03:00
|
|
|
|
2020-04-29 16:36:45 +03:00
|
|
|
out_release:
|
|
|
|
ops->release_device(dev);
|
|
|
|
|
2020-04-29 16:37:11 +03:00
|
|
|
out_module_put:
|
2019-12-19 15:03:41 +03:00
|
|
|
module_put(ops->owner);
|
2020-04-29 16:37:11 +03:00
|
|
|
|
|
|
|
err_free:
|
2020-03-26 18:08:30 +03:00
|
|
|
dev_iommu_free(dev);
|
2020-04-29 16:37:11 +03:00
|
|
|
|
2018-12-20 12:02:20 +03:00
|
|
|
return ret;
|
2018-11-30 12:31:59 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
int iommu_probe_device(struct device *dev)
|
2018-11-30 12:31:59 +03:00
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
2020-04-29 16:36:48 +03:00
|
|
|
struct iommu_group *group;
|
|
|
|
int ret;
|
2018-11-30 12:31:59 +03:00
|
|
|
|
2020-04-29 16:36:48 +03:00
|
|
|
ret = __iommu_probe_device(dev, NULL);
|
|
|
|
if (ret)
|
|
|
|
goto err_out;
|
|
|
|
|
2020-05-25 16:01:22 +03:00
|
|
|
group = iommu_group_get(dev);
|
2020-11-26 16:38:25 +03:00
|
|
|
if (!group) {
|
|
|
|
ret = -ENODEV;
|
2020-05-25 16:01:22 +03:00
|
|
|
goto err_release;
|
2020-11-26 16:38:25 +03:00
|
|
|
}
|
2020-05-25 16:01:22 +03:00
|
|
|
|
2020-04-29 16:36:48 +03:00
|
|
|
/*
|
|
|
|
* Try to allocate a default domain - needs support from the
|
|
|
|
* IOMMU driver. There are still some drivers which don't
|
|
|
|
* support default domains, so the return value is not yet
|
|
|
|
* checked.
|
|
|
|
*/
|
2021-08-10 07:44:00 +03:00
|
|
|
mutex_lock(&group->mutex);
|
2020-05-25 16:01:22 +03:00
|
|
|
iommu_alloc_default_domain(group, dev);
|
2021-08-10 07:44:00 +03:00
|
|
|
mutex_unlock(&group->mutex);
|
2020-04-29 16:36:48 +03:00
|
|
|
|
2020-11-19 19:58:46 +03:00
|
|
|
if (group->default_domain) {
|
2020-04-29 16:36:48 +03:00
|
|
|
ret = __iommu_attach_device(group->default_domain, dev);
|
2020-11-19 19:58:46 +03:00
|
|
|
if (ret) {
|
|
|
|
iommu_group_put(group);
|
|
|
|
goto err_release;
|
|
|
|
}
|
|
|
|
}
|
2020-04-29 16:36:48 +03:00
|
|
|
|
2020-04-29 16:36:50 +03:00
|
|
|
iommu_create_device_direct_mappings(group, dev);
|
|
|
|
|
2020-04-29 16:36:48 +03:00
|
|
|
iommu_group_put(group);
|
|
|
|
|
|
|
|
if (ops->probe_finalize)
|
|
|
|
ops->probe_finalize(dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_release:
|
|
|
|
iommu_release_device(dev);
|
2020-04-29 16:37:10 +03:00
|
|
|
|
2020-04-29 16:36:48 +03:00
|
|
|
err_out:
|
|
|
|
return ret;
|
2019-06-03 17:57:48 +03:00
|
|
|
|
2018-11-30 12:31:59 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
void iommu_release_device(struct device *dev)
|
2018-11-30 12:31:59 +03:00
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
2019-12-19 15:03:41 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
if (!dev->iommu)
|
|
|
|
return;
|
2020-04-29 16:36:45 +03:00
|
|
|
|
|
|
|
iommu_device_unlink(dev->iommu->iommu_dev, dev);
|
|
|
|
|
|
|
|
ops->release_device(dev);
|
2019-06-03 17:57:48 +03:00
|
|
|
|
2020-07-04 03:10:03 +03:00
|
|
|
iommu_group_remove_device(dev);
|
2020-04-29 16:36:45 +03:00
|
|
|
module_put(ops->owner);
|
|
|
|
dev_iommu_free(dev);
|
2018-11-30 12:31:59 +03:00
|
|
|
}
|
2015-05-28 19:41:29 +03:00
|
|
|
|
2017-01-05 21:38:26 +03:00
|
|
|
static int __init iommu_set_def_domain_type(char *str)
|
|
|
|
{
|
|
|
|
bool pt;
|
2018-05-14 19:22:25 +03:00
|
|
|
int ret;
|
2017-01-05 21:38:26 +03:00
|
|
|
|
2018-05-14 19:22:25 +03:00
|
|
|
ret = kstrtobool(str, &pt);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2017-01-05 21:38:26 +03:00
|
|
|
|
2019-08-19 16:22:48 +03:00
|
|
|
if (pt)
|
|
|
|
iommu_set_default_passthrough(true);
|
|
|
|
else
|
|
|
|
iommu_set_default_translated(true);
|
2019-08-19 16:22:46 +03:00
|
|
|
|
2017-01-05 21:38:26 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("iommu.passthrough", iommu_set_def_domain_type);
|
|
|
|
|
2018-09-20 19:10:23 +03:00
|
|
|
static int __init iommu_dma_setup(char *str)
|
|
|
|
{
|
2021-04-01 18:52:54 +03:00
|
|
|
int ret = kstrtobool(str, &iommu_dma_strict);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
iommu_cmd_line |= IOMMU_CMD_LINE_STRICT;
|
|
|
|
return ret;
|
2018-09-20 19:10:23 +03:00
|
|
|
}
|
|
|
|
early_param("iommu.strict", iommu_dma_setup);
|
|
|
|
|
2021-07-12 14:12:20 +03:00
|
|
|
void iommu_set_dma_strict(void)
|
2021-04-01 18:52:54 +03:00
|
|
|
{
|
2021-07-12 14:12:20 +03:00
|
|
|
iommu_dma_strict = true;
|
2021-08-11 15:21:34 +03:00
|
|
|
if (iommu_def_domain_type == IOMMU_DOMAIN_DMA_FQ)
|
|
|
|
iommu_def_domain_type = IOMMU_DOMAIN_DMA;
|
2021-04-01 18:52:54 +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
|
|
|
static ssize_t iommu_group_attr_show(struct kobject *kobj,
|
|
|
|
struct attribute *__attr, char *buf)
|
2011-10-21 23:56:05 +04: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
|
|
|
struct iommu_group_attribute *attr = to_iommu_group_attr(__attr);
|
|
|
|
struct iommu_group *group = to_iommu_group(kobj);
|
|
|
|
ssize_t ret = -EIO;
|
2011-10-21 23:56:05 +04: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
|
|
|
if (attr->show)
|
|
|
|
ret = attr->show(group, buf);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t iommu_group_attr_store(struct kobject *kobj,
|
|
|
|
struct attribute *__attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct iommu_group_attribute *attr = to_iommu_group_attr(__attr);
|
|
|
|
struct iommu_group *group = to_iommu_group(kobj);
|
|
|
|
ssize_t ret = -EIO;
|
2011-10-21 23:56:05 +04: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
|
|
|
if (attr->store)
|
|
|
|
ret = attr->store(group, buf, count);
|
|
|
|
return ret;
|
2011-10-21 23:56:05 +04: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
|
|
|
static const struct sysfs_ops iommu_group_sysfs_ops = {
|
|
|
|
.show = iommu_group_attr_show,
|
|
|
|
.store = iommu_group_attr_store,
|
|
|
|
};
|
2011-10-21 23:56:05 +04: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
|
|
|
static int iommu_group_create_file(struct iommu_group *group,
|
|
|
|
struct iommu_group_attribute *attr)
|
|
|
|
{
|
|
|
|
return sysfs_create_file(&group->kobj, &attr->attr);
|
2011-10-21 23:56:05 +04: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
|
|
|
static void iommu_group_remove_file(struct iommu_group *group,
|
|
|
|
struct iommu_group_attribute *attr)
|
|
|
|
{
|
|
|
|
sysfs_remove_file(&group->kobj, &attr->attr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t iommu_group_show_name(struct iommu_group *group, char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%s\n", group->name);
|
|
|
|
}
|
|
|
|
|
2017-01-19 23:57:51 +03:00
|
|
|
/**
|
|
|
|
* iommu_insert_resv_region - Insert a new region in the
|
|
|
|
* list of reserved regions.
|
|
|
|
* @new: new region to insert
|
|
|
|
* @regions: list of regions
|
|
|
|
*
|
2019-08-21 15:09:40 +03:00
|
|
|
* Elements are sorted by start address and overlapping segments
|
|
|
|
* of the same type are merged.
|
2017-01-19 23:57:51 +03:00
|
|
|
*/
|
2020-07-13 17:25:42 +03:00
|
|
|
static int iommu_insert_resv_region(struct iommu_resv_region *new,
|
|
|
|
struct list_head *regions)
|
2017-01-19 23:57:51 +03:00
|
|
|
{
|
2019-08-21 15:09:40 +03:00
|
|
|
struct iommu_resv_region *iter, *tmp, *nr, *top;
|
|
|
|
LIST_HEAD(stack);
|
|
|
|
|
|
|
|
nr = iommu_alloc_resv_region(new->start, new->length,
|
|
|
|
new->prot, new->type);
|
|
|
|
if (!nr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* First add the new element based on start address sorting */
|
|
|
|
list_for_each_entry(iter, regions, list) {
|
|
|
|
if (nr->start < iter->start ||
|
|
|
|
(nr->start == iter->start && nr->type <= iter->type))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
list_add_tail(&nr->list, &iter->list);
|
|
|
|
|
|
|
|
/* Merge overlapping segments of type nr->type in @regions, if any */
|
|
|
|
list_for_each_entry_safe(iter, tmp, regions, list) {
|
|
|
|
phys_addr_t top_end, iter_end = iter->start + iter->length - 1;
|
|
|
|
|
2019-11-26 20:54:13 +03:00
|
|
|
/* no merge needed on elements of different types than @new */
|
|
|
|
if (iter->type != new->type) {
|
2019-08-21 15:09:40 +03:00
|
|
|
list_move_tail(&iter->list, &stack);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* look for the last stack element of same type as @iter */
|
|
|
|
list_for_each_entry_reverse(top, &stack, list)
|
|
|
|
if (top->type == iter->type)
|
|
|
|
goto check_overlap;
|
|
|
|
|
|
|
|
list_move_tail(&iter->list, &stack);
|
|
|
|
continue;
|
|
|
|
|
|
|
|
check_overlap:
|
|
|
|
top_end = top->start + top->length - 1;
|
|
|
|
|
|
|
|
if (iter->start > top_end + 1) {
|
|
|
|
list_move_tail(&iter->list, &stack);
|
2017-01-19 23:57:51 +03:00
|
|
|
} else {
|
2019-08-21 15:09:40 +03:00
|
|
|
top->length = max(top_end, iter_end) - top->start + 1;
|
|
|
|
list_del(&iter->list);
|
|
|
|
kfree(iter);
|
2017-01-19 23:57:51 +03:00
|
|
|
}
|
|
|
|
}
|
2019-08-21 15:09:40 +03:00
|
|
|
list_splice(&stack, regions);
|
2017-01-19 23:57:51 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
iommu_insert_device_resv_regions(struct list_head *dev_resv_regions,
|
|
|
|
struct list_head *group_resv_regions)
|
|
|
|
{
|
|
|
|
struct iommu_resv_region *entry;
|
2017-02-06 12:11:38 +03:00
|
|
|
int ret = 0;
|
2017-01-19 23:57:51 +03:00
|
|
|
|
|
|
|
list_for_each_entry(entry, dev_resv_regions, list) {
|
|
|
|
ret = iommu_insert_resv_region(entry, group_resv_regions);
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int iommu_get_group_resv_regions(struct iommu_group *group,
|
|
|
|
struct list_head *head)
|
|
|
|
{
|
2017-02-10 17:13:10 +03:00
|
|
|
struct group_device *device;
|
2017-01-19 23:57:51 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
list_for_each_entry(device, &group->devices, list) {
|
|
|
|
struct list_head dev_resv_regions;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&dev_resv_regions);
|
|
|
|
iommu_get_resv_regions(device->dev, &dev_resv_regions);
|
|
|
|
ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
|
|
|
|
iommu_put_resv_regions(device->dev, &dev_resv_regions);
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_get_group_resv_regions);
|
|
|
|
|
2017-01-19 23:57:52 +03:00
|
|
|
static ssize_t iommu_group_show_resv_regions(struct iommu_group *group,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct iommu_resv_region *region, *next;
|
|
|
|
struct list_head group_resv_regions;
|
|
|
|
char *str = buf;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&group_resv_regions);
|
|
|
|
iommu_get_group_resv_regions(group, &group_resv_regions);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(region, next, &group_resv_regions, list) {
|
|
|
|
str += sprintf(str, "0x%016llx 0x%016llx %s\n",
|
|
|
|
(long long int)region->start,
|
|
|
|
(long long int)(region->start +
|
|
|
|
region->length - 1),
|
|
|
|
iommu_group_resv_type_string[region->type]);
|
|
|
|
kfree(region);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (str - buf);
|
|
|
|
}
|
|
|
|
|
2018-07-11 23:59:36 +03:00
|
|
|
static ssize_t iommu_group_show_type(struct iommu_group *group,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
char *type = "unknown\n";
|
|
|
|
|
2020-11-24 16:06:03 +03:00
|
|
|
mutex_lock(&group->mutex);
|
2018-07-11 23:59:36 +03:00
|
|
|
if (group->default_domain) {
|
|
|
|
switch (group->default_domain->type) {
|
|
|
|
case IOMMU_DOMAIN_BLOCKED:
|
|
|
|
type = "blocked\n";
|
|
|
|
break;
|
|
|
|
case IOMMU_DOMAIN_IDENTITY:
|
|
|
|
type = "identity\n";
|
|
|
|
break;
|
|
|
|
case IOMMU_DOMAIN_UNMANAGED:
|
|
|
|
type = "unmanaged\n";
|
|
|
|
break;
|
|
|
|
case IOMMU_DOMAIN_DMA:
|
2019-05-24 09:30:56 +03:00
|
|
|
type = "DMA\n";
|
2018-07-11 23:59:36 +03:00
|
|
|
break;
|
2021-08-11 15:21:30 +03:00
|
|
|
case IOMMU_DOMAIN_DMA_FQ:
|
|
|
|
type = "DMA-FQ\n";
|
|
|
|
break;
|
2018-07-11 23:59:36 +03:00
|
|
|
}
|
|
|
|
}
|
2020-11-24 16:06:03 +03:00
|
|
|
mutex_unlock(&group->mutex);
|
2018-07-11 23:59:36 +03:00
|
|
|
strcpy(buf, type);
|
|
|
|
|
|
|
|
return strlen(type);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static IOMMU_GROUP_ATTR(name, S_IRUGO, iommu_group_show_name, NULL);
|
|
|
|
|
2017-01-19 23:57:52 +03:00
|
|
|
static IOMMU_GROUP_ATTR(reserved_regions, 0444,
|
|
|
|
iommu_group_show_resv_regions, NULL);
|
|
|
|
|
2020-11-24 16:06:02 +03:00
|
|
|
static IOMMU_GROUP_ATTR(type, 0644, iommu_group_show_type,
|
|
|
|
iommu_group_store_type);
|
2018-07-11 23:59:36 +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
|
|
|
static void iommu_group_release(struct kobject *kobj)
|
|
|
|
{
|
|
|
|
struct iommu_group *group = to_iommu_group(kobj);
|
|
|
|
|
2015-05-28 19:41:25 +03:00
|
|
|
pr_debug("Releasing group %d\n", group->id);
|
|
|
|
|
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
|
|
|
if (group->iommu_data_release)
|
|
|
|
group->iommu_data_release(group->iommu_data);
|
|
|
|
|
2016-06-29 22:13:59 +03:00
|
|
|
ida_simple_remove(&iommu_group_ida, group->id);
|
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
|
|
|
|
2015-05-28 19:41:29 +03:00
|
|
|
if (group->default_domain)
|
|
|
|
iommu_domain_free(group->default_domain);
|
|
|
|
|
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
|
|
|
kfree(group->name);
|
|
|
|
kfree(group);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct kobj_type iommu_group_ktype = {
|
|
|
|
.sysfs_ops = &iommu_group_sysfs_ops,
|
|
|
|
.release = iommu_group_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_group_alloc - Allocate a new group
|
|
|
|
*
|
|
|
|
* This function is called by an iommu driver to allocate a new iommu
|
|
|
|
* group. The iommu group represents the minimum granularity of the iommu.
|
|
|
|
* Upon successful return, the caller holds a reference to the supplied
|
|
|
|
* group in order to hold the group until devices are added. Use
|
|
|
|
* iommu_group_put() to release this extra reference count, allowing the
|
|
|
|
* group to be automatically reclaimed once it has no devices or external
|
|
|
|
* references.
|
|
|
|
*/
|
|
|
|
struct iommu_group *iommu_group_alloc(void)
|
2011-10-21 23:56:05 +04: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
|
|
|
struct iommu_group *group;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
group = kzalloc(sizeof(*group), GFP_KERNEL);
|
|
|
|
if (!group)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
group->kobj.kset = iommu_group_kset;
|
|
|
|
mutex_init(&group->mutex);
|
|
|
|
INIT_LIST_HEAD(&group->devices);
|
2020-04-29 16:36:47 +03:00
|
|
|
INIT_LIST_HEAD(&group->entry);
|
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
|
|
|
BLOCKING_INIT_NOTIFIER_HEAD(&group->notifier);
|
|
|
|
|
2016-06-29 22:13:59 +03:00
|
|
|
ret = ida_simple_get(&iommu_group_ida, 0, 0, GFP_KERNEL);
|
|
|
|
if (ret < 0) {
|
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
|
|
|
kfree(group);
|
2016-06-29 22:13:59 +03:00
|
|
|
return ERR_PTR(ret);
|
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
|
|
|
}
|
2016-06-29 22:13:59 +03:00
|
|
|
group->id = ret;
|
2011-10-21 23:56:05 +04: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
|
|
|
ret = kobject_init_and_add(&group->kobj, &iommu_group_ktype,
|
|
|
|
NULL, "%d", group->id);
|
|
|
|
if (ret) {
|
2016-06-29 22:13:59 +03:00
|
|
|
ida_simple_remove(&iommu_group_ida, group->id);
|
2020-05-28 00:00:19 +03:00
|
|
|
kobject_put(&group->kobj);
|
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(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
group->devices_kobj = kobject_create_and_add("devices", &group->kobj);
|
|
|
|
if (!group->devices_kobj) {
|
|
|
|
kobject_put(&group->kobj); /* triggers .release & free */
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The devices_kobj holds a reference on the group kobject, so
|
|
|
|
* as long as that exists so will the group. We can therefore
|
|
|
|
* use the devices_kobj for reference counting.
|
|
|
|
*/
|
|
|
|
kobject_put(&group->kobj);
|
|
|
|
|
2017-01-19 23:57:52 +03:00
|
|
|
ret = iommu_group_create_file(group,
|
|
|
|
&iommu_group_attr_reserved_regions);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
2018-07-11 23:59:36 +03:00
|
|
|
ret = iommu_group_create_file(group, &iommu_group_attr_type);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
2015-05-28 19:41:25 +03:00
|
|
|
pr_debug("Allocated group %d\n", group->id);
|
|
|
|
|
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 group;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_alloc);
|
|
|
|
|
2013-03-25 03:23:49 +04:00
|
|
|
struct iommu_group *iommu_group_get_by_id(int id)
|
|
|
|
{
|
|
|
|
struct kobject *group_kobj;
|
|
|
|
struct iommu_group *group;
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
if (!iommu_group_kset)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
name = kasprintf(GFP_KERNEL, "%d", id);
|
|
|
|
if (!name)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
group_kobj = kset_find_obj(iommu_group_kset, name);
|
|
|
|
kfree(name);
|
|
|
|
|
|
|
|
if (!group_kobj)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
group = container_of(group_kobj, struct iommu_group, kobj);
|
|
|
|
BUG_ON(group->id != id);
|
|
|
|
|
|
|
|
kobject_get(group->devices_kobj);
|
|
|
|
kobject_put(&group->kobj);
|
|
|
|
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_get_by_id);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* iommu_group_get_iommudata - retrieve iommu_data registered for a group
|
|
|
|
* @group: the group
|
|
|
|
*
|
|
|
|
* iommu drivers can store data in the group for use when doing iommu
|
|
|
|
* operations. This function provides a way to retrieve it. Caller
|
|
|
|
* should hold a group reference.
|
|
|
|
*/
|
|
|
|
void *iommu_group_get_iommudata(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
return group->iommu_data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_get_iommudata);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_group_set_iommudata - set iommu_data for a group
|
|
|
|
* @group: the group
|
|
|
|
* @iommu_data: new data
|
|
|
|
* @release: release function for iommu_data
|
|
|
|
*
|
|
|
|
* iommu drivers can store data in the group for use when doing iommu
|
|
|
|
* operations. This function provides a way to set the data after
|
|
|
|
* the group has been allocated. Caller should hold a group reference.
|
|
|
|
*/
|
|
|
|
void iommu_group_set_iommudata(struct iommu_group *group, void *iommu_data,
|
|
|
|
void (*release)(void *iommu_data))
|
2011-10-21 23:56:05 +04: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
|
|
|
group->iommu_data = iommu_data;
|
|
|
|
group->iommu_data_release = release;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_set_iommudata);
|
2011-10-21 23:56:05 +04: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
|
|
|
/**
|
|
|
|
* iommu_group_set_name - set name for a group
|
|
|
|
* @group: the group
|
|
|
|
* @name: name
|
|
|
|
*
|
|
|
|
* Allow iommu driver to set a name for a group. When set it will
|
|
|
|
* appear in a name attribute file under the group in sysfs.
|
|
|
|
*/
|
|
|
|
int iommu_group_set_name(struct iommu_group *group, const char *name)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (group->name) {
|
|
|
|
iommu_group_remove_file(group, &iommu_group_attr_name);
|
|
|
|
kfree(group->name);
|
|
|
|
group->name = NULL;
|
|
|
|
if (!name)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
group->name = kstrdup(name, GFP_KERNEL);
|
|
|
|
if (!group->name)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
ret = iommu_group_create_file(group, &iommu_group_attr_name);
|
|
|
|
if (ret) {
|
|
|
|
kfree(group->name);
|
|
|
|
group->name = NULL;
|
|
|
|
return ret;
|
|
|
|
}
|
2011-10-21 23:56:05 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
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
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_set_name);
|
2011-10-21 23:56:05 +04:00
|
|
|
|
2020-04-29 16:36:50 +03:00
|
|
|
static int iommu_create_device_direct_mappings(struct iommu_group *group,
|
|
|
|
struct device *dev)
|
2015-05-28 19:41:34 +03:00
|
|
|
{
|
|
|
|
struct iommu_domain *domain = group->default_domain;
|
2017-01-19 23:57:47 +03:00
|
|
|
struct iommu_resv_region *entry;
|
2015-05-28 19:41:34 +03:00
|
|
|
struct list_head mappings;
|
|
|
|
unsigned long pg_size;
|
|
|
|
int ret = 0;
|
|
|
|
|
2021-08-11 15:21:30 +03:00
|
|
|
if (!domain || !iommu_is_dma_domain(domain))
|
2015-05-28 19:41:34 +03:00
|
|
|
return 0;
|
|
|
|
|
2016-04-07 20:42:06 +03:00
|
|
|
BUG_ON(!domain->pgsize_bitmap);
|
2015-05-28 19:41:34 +03:00
|
|
|
|
2016-04-07 20:42:06 +03:00
|
|
|
pg_size = 1UL << __ffs(domain->pgsize_bitmap);
|
2015-05-28 19:41:34 +03:00
|
|
|
INIT_LIST_HEAD(&mappings);
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
iommu_get_resv_regions(dev, &mappings);
|
2015-05-28 19:41:34 +03:00
|
|
|
|
|
|
|
/* We need to consider overlapping regions for different devices */
|
|
|
|
list_for_each_entry(entry, &mappings, list) {
|
|
|
|
dma_addr_t start, end, addr;
|
2020-12-07 12:35:53 +03:00
|
|
|
size_t map_size = 0;
|
2015-05-28 19:41:34 +03:00
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
if (domain->ops->apply_resv_region)
|
|
|
|
domain->ops->apply_resv_region(dev, domain, entry);
|
2016-07-05 14:07:53 +03:00
|
|
|
|
2015-05-28 19:41:34 +03:00
|
|
|
start = ALIGN(entry->start, pg_size);
|
|
|
|
end = ALIGN(entry->start + entry->length, pg_size);
|
|
|
|
|
2019-06-03 09:53:35 +03:00
|
|
|
if (entry->type != IOMMU_RESV_DIRECT &&
|
|
|
|
entry->type != IOMMU_RESV_DIRECT_RELAXABLE)
|
2017-01-19 23:57:50 +03:00
|
|
|
continue;
|
|
|
|
|
2020-12-07 12:35:53 +03:00
|
|
|
for (addr = start; addr <= end; addr += pg_size) {
|
2015-05-28 19:41:34 +03:00
|
|
|
phys_addr_t phys_addr;
|
|
|
|
|
2020-12-07 12:35:53 +03:00
|
|
|
if (addr == end)
|
|
|
|
goto map_end;
|
|
|
|
|
2015-05-28 19:41:34 +03:00
|
|
|
phys_addr = iommu_iova_to_phys(domain, addr);
|
2020-12-07 12:35:53 +03:00
|
|
|
if (!phys_addr) {
|
|
|
|
map_size += pg_size;
|
2015-05-28 19:41:34 +03:00
|
|
|
continue;
|
2020-12-07 12:35:53 +03:00
|
|
|
}
|
2015-05-28 19:41:34 +03:00
|
|
|
|
2020-12-07 12:35:53 +03:00
|
|
|
map_end:
|
|
|
|
if (map_size) {
|
|
|
|
ret = iommu_map(domain, addr - map_size,
|
|
|
|
addr - map_size, map_size,
|
|
|
|
entry->prot);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
map_size = 0;
|
|
|
|
}
|
2015-05-28 19:41:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2020-08-18 00:00:49 +03:00
|
|
|
iommu_flush_iotlb_all(domain);
|
2017-08-23 16:50:04 +03:00
|
|
|
|
2015-05-28 19:41:34 +03:00
|
|
|
out:
|
2017-01-19 23:57:47 +03:00
|
|
|
iommu_put_resv_regions(dev, &mappings);
|
2015-05-28 19:41:34 +03:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-05-19 16:03:40 +03:00
|
|
|
static bool iommu_is_attach_deferred(struct iommu_domain *domain,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
if (domain->ops->is_attach_deferred)
|
|
|
|
return domain->ops->is_attach_deferred(domain, dev);
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* iommu_group_add_device - add a device to an iommu group
|
|
|
|
* @group: the group into which to add the device (reference should be held)
|
|
|
|
* @dev: the device
|
|
|
|
*
|
|
|
|
* This function is called by an iommu driver to add a device into a
|
|
|
|
* group. Adding a device increments the group reference count.
|
|
|
|
*/
|
|
|
|
int iommu_group_add_device(struct iommu_group *group, struct device *dev)
|
2011-10-21 23:56:05 +04: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
|
|
|
int ret, i = 0;
|
2017-02-01 14:19:46 +03:00
|
|
|
struct group_device *device;
|
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
|
|
|
|
|
|
|
device = kzalloc(sizeof(*device), GFP_KERNEL);
|
|
|
|
if (!device)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
device->dev = dev;
|
2011-10-21 23:56:05 +04: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
|
|
|
ret = sysfs_create_link(&dev->kobj, &group->kobj, "iommu_group");
|
2017-01-16 15:58:07 +03:00
|
|
|
if (ret)
|
|
|
|
goto err_free_device;
|
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
|
|
|
|
|
|
|
device->name = kasprintf(GFP_KERNEL, "%s", kobject_name(&dev->kobj));
|
|
|
|
rename:
|
|
|
|
if (!device->name) {
|
2017-01-16 15:58:07 +03:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_remove_link;
|
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
|
|
|
}
|
2011-10-21 23:56:05 +04: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
|
|
|
ret = sysfs_create_link_nowarn(group->devices_kobj,
|
|
|
|
&dev->kobj, device->name);
|
|
|
|
if (ret) {
|
|
|
|
if (ret == -EEXIST && i >= 0) {
|
|
|
|
/*
|
|
|
|
* Account for the slim chance of collision
|
|
|
|
* and append an instance to the name.
|
|
|
|
*/
|
2017-01-16 15:58:07 +03:00
|
|
|
kfree(device->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
|
|
|
device->name = kasprintf(GFP_KERNEL, "%s.%d",
|
|
|
|
kobject_name(&dev->kobj), i++);
|
|
|
|
goto rename;
|
|
|
|
}
|
2017-01-16 15:58:07 +03:00
|
|
|
goto err_free_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
|
|
|
}
|
|
|
|
|
|
|
|
kobject_get(group->devices_kobj);
|
|
|
|
|
|
|
|
dev->iommu_group = group;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
list_add_tail(&device->list, &group->devices);
|
2020-05-19 16:03:40 +03:00
|
|
|
if (group->domain && !iommu_is_attach_deferred(group->domain, dev))
|
2017-01-16 15:58:07 +03:00
|
|
|
ret = __iommu_attach_device(group->domain, 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
|
|
|
mutex_unlock(&group->mutex);
|
2017-01-16 15:58:07 +03:00
|
|
|
if (ret)
|
|
|
|
goto err_put_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
|
|
|
|
|
|
|
/* Notify any listeners about change to group. */
|
|
|
|
blocking_notifier_call_chain(&group->notifier,
|
|
|
|
IOMMU_GROUP_NOTIFY_ADD_DEVICE, dev);
|
2013-08-15 21:59:24 +04:00
|
|
|
|
|
|
|
trace_add_device_to_group(group->id, dev);
|
2015-05-28 19:41:25 +03:00
|
|
|
|
2019-02-09 01:05:45 +03:00
|
|
|
dev_info(dev, "Adding to iommu group %d\n", group->id);
|
2015-05-28 19:41:25 +03:00
|
|
|
|
2011-10-21 23:56:05 +04:00
|
|
|
return 0;
|
2017-01-16 15:58:07 +03:00
|
|
|
|
|
|
|
err_put_group:
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
list_del(&device->list);
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
dev->iommu_group = NULL;
|
|
|
|
kobject_put(group->devices_kobj);
|
2019-12-31 23:24:19 +03:00
|
|
|
sysfs_remove_link(group->devices_kobj, device->name);
|
2017-01-16 15:58:07 +03:00
|
|
|
err_free_name:
|
|
|
|
kfree(device->name);
|
|
|
|
err_remove_link:
|
|
|
|
sysfs_remove_link(&dev->kobj, "iommu_group");
|
|
|
|
err_free_device:
|
|
|
|
kfree(device);
|
2019-02-09 01:05:45 +03:00
|
|
|
dev_err(dev, "Failed to add to iommu group %d: %d\n", group->id, ret);
|
2017-01-16 15:58:07 +03:00
|
|
|
return ret;
|
2011-10-21 23:56:05 +04: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
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_add_device);
|
2011-10-21 23:56:05 +04: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
|
|
|
/**
|
|
|
|
* iommu_group_remove_device - remove a device from it's current group
|
|
|
|
* @dev: device to be removed
|
|
|
|
*
|
|
|
|
* This function is called by an iommu driver to remove the device from
|
|
|
|
* it's current group. This decrements the iommu group reference count.
|
|
|
|
*/
|
|
|
|
void iommu_group_remove_device(struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_group *group = dev->iommu_group;
|
2017-02-01 14:19:46 +03:00
|
|
|
struct group_device *tmp_device, *device = NULL;
|
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
|
|
|
|
2021-07-31 10:47:37 +03:00
|
|
|
if (!group)
|
|
|
|
return;
|
|
|
|
|
2019-02-09 01:05:45 +03:00
|
|
|
dev_info(dev, "Removing from iommu group %d\n", group->id);
|
2015-05-28 19:41:25 +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
|
|
|
/* Pre-notify listeners that a device is being removed. */
|
|
|
|
blocking_notifier_call_chain(&group->notifier,
|
|
|
|
IOMMU_GROUP_NOTIFY_DEL_DEVICE, dev);
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
list_for_each_entry(tmp_device, &group->devices, list) {
|
|
|
|
if (tmp_device->dev == dev) {
|
|
|
|
device = tmp_device;
|
|
|
|
list_del(&device->list);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
if (!device)
|
|
|
|
return;
|
|
|
|
|
|
|
|
sysfs_remove_link(group->devices_kobj, device->name);
|
|
|
|
sysfs_remove_link(&dev->kobj, "iommu_group");
|
|
|
|
|
2013-08-15 21:59:25 +04:00
|
|
|
trace_remove_device_from_group(group->id, 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
|
|
|
kfree(device->name);
|
|
|
|
kfree(device);
|
|
|
|
dev->iommu_group = NULL;
|
|
|
|
kobject_put(group->devices_kobj);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_remove_device);
|
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
static int iommu_group_device_count(struct iommu_group *group)
|
|
|
|
{
|
2017-02-01 14:19:46 +03:00
|
|
|
struct group_device *entry;
|
2015-05-28 19:41:30 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(entry, &group->devices, list)
|
|
|
|
ret++;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* iommu_group_for_each_dev - iterate over each device in the group
|
|
|
|
* @group: the group
|
|
|
|
* @data: caller opaque data to be passed to callback function
|
|
|
|
* @fn: caller supplied callback function
|
|
|
|
*
|
|
|
|
* This function is called by group users to iterate over group devices.
|
|
|
|
* Callers should hold a reference count to the group during callback.
|
|
|
|
* The group->mutex is held across callbacks, which will block calls to
|
|
|
|
* iommu_group_add/remove_device.
|
|
|
|
*/
|
2015-05-28 19:41:31 +03:00
|
|
|
static 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
|
|
|
{
|
2017-02-01 14:19:46 +03:00
|
|
|
struct group_device *device;
|
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
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(device, &group->devices, list) {
|
|
|
|
ret = fn(device->dev, data);
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
2015-05-28 19:41:31 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int iommu_group_for_each_dev(struct iommu_group *group, void *data,
|
|
|
|
int (*fn)(struct device *, void *))
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
ret = __iommu_group_for_each_dev(group, data, fn);
|
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
|
|
|
mutex_unlock(&group->mutex);
|
2015-05-28 19:41:31 +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
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_for_each_dev);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_group_get - Return the group for a device and increment reference
|
|
|
|
* @dev: get the group that this device belongs to
|
|
|
|
*
|
|
|
|
* This function is called by iommu drivers and users to get the group
|
|
|
|
* for the specified device. If found, the group is returned and the group
|
|
|
|
* reference in incremented, else NULL.
|
|
|
|
*/
|
|
|
|
struct iommu_group *iommu_group_get(struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_group *group = dev->iommu_group;
|
|
|
|
|
|
|
|
if (group)
|
|
|
|
kobject_get(group->devices_kobj);
|
|
|
|
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_get);
|
|
|
|
|
2016-11-11 20:59:21 +03:00
|
|
|
/**
|
|
|
|
* iommu_group_ref_get - Increment reference on a group
|
|
|
|
* @group: the group to use, must not be NULL
|
|
|
|
*
|
|
|
|
* This function is called by iommu drivers to take additional references on an
|
|
|
|
* existing group. Returns the given group for convenience.
|
|
|
|
*/
|
|
|
|
struct iommu_group *iommu_group_ref_get(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
kobject_get(group->devices_kobj);
|
|
|
|
return group;
|
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_ref_get);
|
2016-11-11 20:59:21 +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
|
|
|
/**
|
|
|
|
* iommu_group_put - Decrement group reference
|
|
|
|
* @group: the group to use
|
|
|
|
*
|
|
|
|
* This function is called by iommu drivers and users to release the
|
|
|
|
* iommu group. Once the reference count is zero, the group is released.
|
|
|
|
*/
|
|
|
|
void iommu_group_put(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
if (group)
|
|
|
|
kobject_put(group->devices_kobj);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_put);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_group_register_notifier - Register a notifier for group changes
|
|
|
|
* @group: the group to watch
|
|
|
|
* @nb: notifier block to signal
|
|
|
|
*
|
|
|
|
* This function allows iommu group users to track changes in a group.
|
|
|
|
* See include/linux/iommu.h for actions sent via this notifier. Caller
|
|
|
|
* should hold a reference to the group throughout notifier registration.
|
|
|
|
*/
|
|
|
|
int iommu_group_register_notifier(struct iommu_group *group,
|
|
|
|
struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_register(&group->notifier, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_register_notifier);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_group_unregister_notifier - Unregister a notifier
|
|
|
|
* @group: the group to watch
|
|
|
|
* @nb: notifier block to signal
|
|
|
|
*
|
|
|
|
* Unregister a previously registered group notifier block.
|
|
|
|
*/
|
|
|
|
int iommu_group_unregister_notifier(struct iommu_group *group,
|
|
|
|
struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_unregister(&group->notifier, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
|
|
|
|
|
2019-06-03 17:57:48 +03:00
|
|
|
/**
|
|
|
|
* iommu_register_device_fault_handler() - Register a device fault handler
|
|
|
|
* @dev: the device
|
|
|
|
* @handler: the fault handler
|
|
|
|
* @data: private data passed as argument to the handler
|
|
|
|
*
|
|
|
|
* When an IOMMU fault event is received, this handler gets called with the
|
2019-06-03 17:57:49 +03:00
|
|
|
* fault event and data as argument. The handler should return 0 on success. If
|
|
|
|
* the fault is recoverable (IOMMU_FAULT_PAGE_REQ), the consumer should also
|
|
|
|
* complete the fault by calling iommu_page_response() with one of the following
|
|
|
|
* response code:
|
|
|
|
* - IOMMU_PAGE_RESP_SUCCESS: retry the translation
|
|
|
|
* - IOMMU_PAGE_RESP_INVALID: terminate the fault
|
|
|
|
* - IOMMU_PAGE_RESP_FAILURE: terminate the fault and stop reporting
|
|
|
|
* page faults if possible.
|
2019-06-03 17:57:48 +03:00
|
|
|
*
|
|
|
|
* Return 0 if the fault handler was installed successfully, or an error.
|
|
|
|
*/
|
|
|
|
int iommu_register_device_fault_handler(struct device *dev,
|
|
|
|
iommu_dev_fault_handler_t handler,
|
|
|
|
void *data)
|
|
|
|
{
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu *param = dev->iommu;
|
2019-06-03 17:57:48 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!param)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(¶m->lock);
|
|
|
|
/* Only allow one fault handler registered for each device */
|
|
|
|
if (param->fault_param) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto done_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
get_device(dev);
|
|
|
|
param->fault_param = kzalloc(sizeof(*param->fault_param), GFP_KERNEL);
|
|
|
|
if (!param->fault_param) {
|
|
|
|
put_device(dev);
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto done_unlock;
|
|
|
|
}
|
|
|
|
param->fault_param->handler = handler;
|
|
|
|
param->fault_param->data = data;
|
2019-06-03 17:57:49 +03:00
|
|
|
mutex_init(¶m->fault_param->lock);
|
|
|
|
INIT_LIST_HEAD(¶m->fault_param->faults);
|
2019-06-03 17:57:48 +03:00
|
|
|
|
|
|
|
done_unlock:
|
|
|
|
mutex_unlock(¶m->lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_register_device_fault_handler);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_unregister_device_fault_handler() - Unregister the device fault handler
|
|
|
|
* @dev: the device
|
|
|
|
*
|
|
|
|
* Remove the device fault handler installed with
|
|
|
|
* iommu_register_device_fault_handler().
|
|
|
|
*
|
|
|
|
* Return 0 on success, or an error.
|
|
|
|
*/
|
|
|
|
int iommu_unregister_device_fault_handler(struct device *dev)
|
|
|
|
{
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu *param = dev->iommu;
|
2019-06-03 17:57:48 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!param)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(¶m->lock);
|
|
|
|
|
|
|
|
if (!param->fault_param)
|
|
|
|
goto unlock;
|
|
|
|
|
2019-06-03 17:57:49 +03:00
|
|
|
/* we cannot unregister handler if there are pending faults */
|
|
|
|
if (!list_empty(¶m->fault_param->faults)) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2019-06-03 17:57:48 +03:00
|
|
|
kfree(param->fault_param);
|
|
|
|
param->fault_param = NULL;
|
|
|
|
put_device(dev);
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(¶m->lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_unregister_device_fault_handler);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_report_device_fault() - Report fault event to device driver
|
|
|
|
* @dev: the device
|
|
|
|
* @evt: fault event data
|
|
|
|
*
|
|
|
|
* Called by IOMMU drivers when a fault is detected, typically in a threaded IRQ
|
2019-06-03 17:57:49 +03:00
|
|
|
* handler. When this function fails and the fault is recoverable, it is the
|
|
|
|
* caller's responsibility to complete the fault.
|
2019-06-03 17:57:48 +03:00
|
|
|
*
|
|
|
|
* Return 0 on success, or an error.
|
|
|
|
*/
|
|
|
|
int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
|
|
|
|
{
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu *param = dev->iommu;
|
2019-06-03 17:57:49 +03:00
|
|
|
struct iommu_fault_event *evt_pending = NULL;
|
2019-06-03 17:57:48 +03:00
|
|
|
struct iommu_fault_param *fparam;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!param || !evt)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* we only report device fault if there is a handler registered */
|
|
|
|
mutex_lock(¶m->lock);
|
|
|
|
fparam = param->fault_param;
|
|
|
|
if (!fparam || !fparam->handler) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto done_unlock;
|
|
|
|
}
|
2019-06-03 17:57:49 +03:00
|
|
|
|
|
|
|
if (evt->fault.type == IOMMU_FAULT_PAGE_REQ &&
|
|
|
|
(evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
|
|
|
|
evt_pending = kmemdup(evt, sizeof(struct iommu_fault_event),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!evt_pending) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto done_unlock;
|
|
|
|
}
|
|
|
|
mutex_lock(&fparam->lock);
|
|
|
|
list_add_tail(&evt_pending->list, &fparam->faults);
|
|
|
|
mutex_unlock(&fparam->lock);
|
|
|
|
}
|
|
|
|
|
2019-06-03 17:57:48 +03:00
|
|
|
ret = fparam->handler(&evt->fault, fparam->data);
|
2019-06-03 17:57:49 +03:00
|
|
|
if (ret && evt_pending) {
|
|
|
|
mutex_lock(&fparam->lock);
|
|
|
|
list_del(&evt_pending->list);
|
|
|
|
mutex_unlock(&fparam->lock);
|
|
|
|
kfree(evt_pending);
|
|
|
|
}
|
2019-06-03 17:57:48 +03:00
|
|
|
done_unlock:
|
|
|
|
mutex_unlock(¶m->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_report_device_fault);
|
|
|
|
|
2019-06-03 17:57:49 +03:00
|
|
|
int iommu_page_response(struct device *dev,
|
|
|
|
struct iommu_page_response *msg)
|
|
|
|
{
|
2020-06-16 17:47:14 +03:00
|
|
|
bool needs_pasid;
|
2019-06-03 17:57:49 +03:00
|
|
|
int ret = -EINVAL;
|
|
|
|
struct iommu_fault_event *evt;
|
|
|
|
struct iommu_fault_page_request *prm;
|
2020-03-26 18:08:30 +03:00
|
|
|
struct dev_iommu *param = dev->iommu;
|
2020-06-16 17:47:14 +03:00
|
|
|
bool has_pasid = msg->flags & IOMMU_PAGE_RESP_PASID_VALID;
|
2019-06-03 17:57:49 +03:00
|
|
|
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
|
|
|
|
|
|
|
|
if (!domain || !domain->ops->page_response)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (!param || !param->fault_param)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (msg->version != IOMMU_PAGE_RESP_VERSION_1 ||
|
|
|
|
msg->flags & ~IOMMU_PAGE_RESP_PASID_VALID)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Only send response if there is a fault report pending */
|
|
|
|
mutex_lock(¶m->fault_param->lock);
|
|
|
|
if (list_empty(¶m->fault_param->faults)) {
|
|
|
|
dev_warn_ratelimited(dev, "no pending PRQ, drop response\n");
|
|
|
|
goto done_unlock;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Check if we have a matching page request pending to respond,
|
|
|
|
* otherwise return -EINVAL
|
|
|
|
*/
|
|
|
|
list_for_each_entry(evt, ¶m->fault_param->faults, list) {
|
|
|
|
prm = &evt->fault.prm;
|
2020-06-16 17:47:14 +03:00
|
|
|
if (prm->grpid != msg->grpid)
|
|
|
|
continue;
|
2019-06-03 17:57:49 +03:00
|
|
|
|
2020-06-16 17:47:14 +03:00
|
|
|
/*
|
|
|
|
* If the PASID is required, the corresponding request is
|
|
|
|
* matched using the group ID, the PASID valid bit and the PASID
|
|
|
|
* value. Otherwise only the group ID matches request and
|
|
|
|
* response.
|
|
|
|
*/
|
|
|
|
needs_pasid = prm->flags & IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID;
|
|
|
|
if (needs_pasid && (!has_pasid || msg->pasid != prm->pasid))
|
2019-06-03 17:57:49 +03:00
|
|
|
continue;
|
|
|
|
|
2020-06-16 17:47:14 +03:00
|
|
|
if (!needs_pasid && has_pasid) {
|
|
|
|
/* No big deal, just clear it. */
|
|
|
|
msg->flags &= ~IOMMU_PAGE_RESP_PASID_VALID;
|
|
|
|
msg->pasid = 0;
|
|
|
|
}
|
2019-06-03 17:57:49 +03:00
|
|
|
|
|
|
|
ret = domain->ops->page_response(dev, evt, msg);
|
|
|
|
list_del(&evt->list);
|
|
|
|
kfree(evt);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
done_unlock:
|
|
|
|
mutex_unlock(¶m->fault_param->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_page_response);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* iommu_group_id - Return ID for a group
|
|
|
|
* @group: the group to ID
|
|
|
|
*
|
|
|
|
* Return the unique ID for the group matching the sysfs group number.
|
|
|
|
*/
|
|
|
|
int iommu_group_id(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
return group->id;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_group_id);
|
2011-10-21 23:56:05 +04:00
|
|
|
|
2014-09-19 20:03:06 +04:00
|
|
|
static struct iommu_group *get_pci_alias_group(struct pci_dev *pdev,
|
|
|
|
unsigned long *devfns);
|
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
/*
|
|
|
|
* To consider a PCI device isolated, we require ACS to support Source
|
|
|
|
* Validation, Request Redirection, Completer Redirection, and Upstream
|
|
|
|
* Forwarding. This effectively means that devices cannot spoof their
|
|
|
|
* requester ID, requests and completions cannot be redirected, and all
|
|
|
|
* transactions are forwarded upstream, even as it passes through a
|
|
|
|
* bridge where the target device is downstream.
|
|
|
|
*/
|
|
|
|
#define REQ_ACS_FLAGS (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
|
|
|
|
|
2014-09-19 20:03:06 +04:00
|
|
|
/*
|
|
|
|
* For multifunction devices which are not isolated from each other, find
|
|
|
|
* all the other non-isolated functions and look for existing groups. For
|
|
|
|
* each function, we also need to look for aliases to or from other devices
|
|
|
|
* that may already have a group.
|
|
|
|
*/
|
|
|
|
static struct iommu_group *get_pci_function_alias_group(struct pci_dev *pdev,
|
|
|
|
unsigned long *devfns)
|
|
|
|
{
|
|
|
|
struct pci_dev *tmp = NULL;
|
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
if (!pdev->multifunction || pci_acs_enabled(pdev, REQ_ACS_FLAGS))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
for_each_pci_dev(tmp) {
|
|
|
|
if (tmp == pdev || tmp->bus != pdev->bus ||
|
|
|
|
PCI_SLOT(tmp->devfn) != PCI_SLOT(pdev->devfn) ||
|
|
|
|
pci_acs_enabled(tmp, REQ_ACS_FLAGS))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
group = get_pci_alias_group(tmp, devfns);
|
|
|
|
if (group) {
|
|
|
|
pci_dev_put(tmp);
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2016-03-03 17:38:02 +03:00
|
|
|
* Look for aliases to or from the given device for existing groups. DMA
|
|
|
|
* aliases are only supported on the same bus, therefore the search
|
2014-09-19 20:03:06 +04:00
|
|
|
* space is quite small (especially since we're really only looking at pcie
|
|
|
|
* device, and therefore only expect multiple slots on the root complex or
|
|
|
|
* downstream switch ports). It's conceivable though that a pair of
|
|
|
|
* multifunction devices could have aliases between them that would cause a
|
|
|
|
* loop. To prevent this, we use a bitmap to track where we've been.
|
|
|
|
*/
|
|
|
|
static struct iommu_group *get_pci_alias_group(struct pci_dev *pdev,
|
|
|
|
unsigned long *devfns)
|
|
|
|
{
|
|
|
|
struct pci_dev *tmp = NULL;
|
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
if (test_and_set_bit(pdev->devfn & 0xff, devfns))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
group = iommu_group_get(&pdev->dev);
|
|
|
|
if (group)
|
|
|
|
return group;
|
|
|
|
|
|
|
|
for_each_pci_dev(tmp) {
|
|
|
|
if (tmp == pdev || tmp->bus != pdev->bus)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* We alias them or they alias us */
|
2016-03-03 17:38:02 +03:00
|
|
|
if (pci_devs_are_dma_aliases(pdev, tmp)) {
|
2014-09-19 20:03:06 +04:00
|
|
|
group = get_pci_alias_group(tmp, devfns);
|
|
|
|
if (group) {
|
|
|
|
pci_dev_put(tmp);
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
|
|
|
|
group = get_pci_function_alias_group(tmp, devfns);
|
|
|
|
if (group) {
|
|
|
|
pci_dev_put(tmp);
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
struct group_for_pci_data {
|
|
|
|
struct pci_dev *pdev;
|
|
|
|
struct iommu_group *group;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* DMA alias iterator callback, return the last seen device. Stop and return
|
|
|
|
* the IOMMU group if we find one along the way.
|
|
|
|
*/
|
|
|
|
static int get_pci_alias_or_group(struct pci_dev *pdev, u16 alias, void *opaque)
|
|
|
|
{
|
|
|
|
struct group_for_pci_data *data = opaque;
|
|
|
|
|
|
|
|
data->pdev = pdev;
|
|
|
|
data->group = iommu_group_get(&pdev->dev);
|
|
|
|
|
|
|
|
return data->group != NULL;
|
|
|
|
}
|
|
|
|
|
2015-10-22 00:51:38 +03:00
|
|
|
/*
|
|
|
|
* Generic device_group call-back function. It just allocates one
|
|
|
|
* iommu-group per device.
|
|
|
|
*/
|
|
|
|
struct iommu_group *generic_device_group(struct device *dev)
|
|
|
|
{
|
2017-06-28 13:45:31 +03:00
|
|
|
return iommu_group_alloc();
|
2015-10-22 00:51:38 +03:00
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(generic_device_group);
|
2015-10-22 00:51:38 +03:00
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
/*
|
|
|
|
* Use standard PCI bus topology, isolation features, and DMA alias quirks
|
|
|
|
* to find or create an IOMMU group for a device.
|
|
|
|
*/
|
2015-10-22 00:51:37 +03:00
|
|
|
struct iommu_group *pci_device_group(struct device *dev)
|
2014-07-03 19:51:18 +04:00
|
|
|
{
|
2015-10-22 00:51:37 +03:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
2014-07-03 19:51:18 +04:00
|
|
|
struct group_for_pci_data data;
|
|
|
|
struct pci_bus *bus;
|
|
|
|
struct iommu_group *group = NULL;
|
2014-09-19 20:03:06 +04:00
|
|
|
u64 devfns[4] = { 0 };
|
2014-07-03 19:51:18 +04:00
|
|
|
|
2015-10-22 00:51:37 +03:00
|
|
|
if (WARN_ON(!dev_is_pci(dev)))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
/*
|
|
|
|
* Find the upstream DMA alias for the device. A device must not
|
|
|
|
* be aliased due to topology in order to have its own IOMMU group.
|
|
|
|
* If we find an alias along the way that already belongs to a
|
|
|
|
* group, use it.
|
|
|
|
*/
|
|
|
|
if (pci_for_each_dma_alias(pdev, get_pci_alias_or_group, &data))
|
|
|
|
return data.group;
|
|
|
|
|
|
|
|
pdev = data.pdev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Continue upstream from the point of minimum IOMMU granularity
|
|
|
|
* due to aliases to the point where devices are protected from
|
|
|
|
* peer-to-peer DMA by PCI ACS. Again, if we find an existing
|
|
|
|
* group, use it.
|
|
|
|
*/
|
|
|
|
for (bus = pdev->bus; !pci_is_root_bus(bus); bus = bus->parent) {
|
|
|
|
if (!bus->self)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (pci_acs_path_enabled(bus->self, NULL, REQ_ACS_FLAGS))
|
|
|
|
break;
|
|
|
|
|
|
|
|
pdev = bus->self;
|
|
|
|
|
|
|
|
group = iommu_group_get(&pdev->dev);
|
|
|
|
if (group)
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-09-19 20:03:06 +04:00
|
|
|
* Look for existing groups on device aliases. If we alias another
|
|
|
|
* device or another device aliases us, use the same group.
|
2014-07-03 19:51:18 +04:00
|
|
|
*/
|
2014-09-19 20:03:06 +04:00
|
|
|
group = get_pci_alias_group(pdev, (unsigned long *)devfns);
|
|
|
|
if (group)
|
|
|
|
return group;
|
2014-07-03 19:51:18 +04:00
|
|
|
|
|
|
|
/*
|
2014-09-19 20:03:06 +04:00
|
|
|
* Look for existing groups on non-isolated functions on the same
|
|
|
|
* slot and aliases of those funcions, if any. No need to clear
|
|
|
|
* the search bitmap, the tested devfns are still valid.
|
2014-07-03 19:51:18 +04:00
|
|
|
*/
|
2014-09-19 20:03:06 +04:00
|
|
|
group = get_pci_function_alias_group(pdev, (unsigned long *)devfns);
|
|
|
|
if (group)
|
|
|
|
return group;
|
2014-07-03 19:51:18 +04:00
|
|
|
|
|
|
|
/* No shared group found, allocate new */
|
2017-06-28 13:45:31 +03:00
|
|
|
return iommu_group_alloc();
|
2014-07-03 19:51:18 +04:00
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(pci_device_group);
|
2014-07-03 19:51:18 +04:00
|
|
|
|
2018-09-10 16:49:18 +03:00
|
|
|
/* Get the IOMMU group for device on fsl-mc bus */
|
|
|
|
struct iommu_group *fsl_mc_device_group(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device *cont_dev = fsl_mc_cont_dev(dev);
|
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
group = iommu_group_get(cont_dev);
|
|
|
|
if (!group)
|
|
|
|
group = iommu_group_alloc();
|
|
|
|
return group;
|
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(fsl_mc_device_group);
|
2018-09-10 16:49:18 +03:00
|
|
|
|
2020-04-29 16:36:40 +03:00
|
|
|
static int iommu_get_def_domain_type(struct device *dev)
|
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
2020-11-24 16:06:01 +03:00
|
|
|
|
|
|
|
if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
|
|
|
|
return IOMMU_DOMAIN_DMA;
|
2020-04-29 16:36:40 +03:00
|
|
|
|
|
|
|
if (ops->def_domain_type)
|
2020-11-24 16:06:01 +03:00
|
|
|
return ops->def_domain_type(dev);
|
2020-04-29 16:36:40 +03:00
|
|
|
|
2020-11-24 16:06:01 +03:00
|
|
|
return 0;
|
2020-04-29 16:36:40 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:46 +03:00
|
|
|
static int iommu_group_alloc_default_domain(struct bus_type *bus,
|
|
|
|
struct iommu_group *group,
|
|
|
|
unsigned int type)
|
2020-04-29 16:36:39 +03:00
|
|
|
{
|
|
|
|
struct iommu_domain *dom;
|
|
|
|
|
2020-04-29 16:36:46 +03:00
|
|
|
dom = __iommu_domain_alloc(bus, type);
|
2020-04-29 16:36:40 +03:00
|
|
|
if (!dom && type != IOMMU_DOMAIN_DMA) {
|
2020-04-29 16:36:46 +03:00
|
|
|
dom = __iommu_domain_alloc(bus, IOMMU_DOMAIN_DMA);
|
|
|
|
if (dom)
|
|
|
|
pr_warn("Failed to allocate default IOMMU domain of type %u for group %s - Falling back to IOMMU_DOMAIN_DMA",
|
|
|
|
type, group->name);
|
2020-04-29 16:36:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!dom)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
group->default_domain = dom;
|
|
|
|
if (!group->domain)
|
|
|
|
group->domain = dom;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-25 16:01:22 +03:00
|
|
|
static int iommu_alloc_default_domain(struct iommu_group *group,
|
|
|
|
struct device *dev)
|
2020-04-29 16:36:46 +03:00
|
|
|
{
|
|
|
|
unsigned int type;
|
|
|
|
|
|
|
|
if (group->default_domain)
|
|
|
|
return 0;
|
|
|
|
|
2020-11-24 16:06:01 +03:00
|
|
|
type = iommu_get_def_domain_type(dev) ? : iommu_def_domain_type;
|
2020-04-29 16:36:46 +03:00
|
|
|
|
|
|
|
return iommu_group_alloc_default_domain(dev->bus, group, type);
|
|
|
|
}
|
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
/**
|
|
|
|
* iommu_group_get_for_dev - Find or create the IOMMU group for a device
|
|
|
|
* @dev: target device
|
|
|
|
*
|
|
|
|
* This function is intended to be called by IOMMU drivers and extended to
|
|
|
|
* support common, bus-defined algorithms when determining or creating the
|
|
|
|
* IOMMU group for a device. On success, the caller will hold a reference
|
|
|
|
* to the returned IOMMU group, which will already include the provided
|
|
|
|
* device. The reference should be released with iommu_group_put().
|
|
|
|
*/
|
2020-04-29 16:37:12 +03:00
|
|
|
static struct iommu_group *iommu_group_get_for_dev(struct device *dev)
|
2014-07-03 19:51:18 +04:00
|
|
|
{
|
2015-10-22 00:51:36 +03:00
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
2014-08-22 00:32:08 +04:00
|
|
|
struct iommu_group *group;
|
2014-07-03 19:51:18 +04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
|
|
|
if (group)
|
|
|
|
return group;
|
|
|
|
|
2017-07-21 15:12:38 +03:00
|
|
|
if (!ops)
|
|
|
|
return ERR_PTR(-EINVAL);
|
2014-07-03 19:51:18 +04:00
|
|
|
|
2017-07-21 15:12:38 +03:00
|
|
|
group = ops->device_group(dev);
|
2017-06-28 13:52:48 +03:00
|
|
|
if (WARN_ON_ONCE(group == NULL))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2014-07-03 19:51:18 +04:00
|
|
|
if (IS_ERR(group))
|
|
|
|
return group;
|
|
|
|
|
|
|
|
ret = iommu_group_add_device(group, dev);
|
2020-04-29 16:36:46 +03:00
|
|
|
if (ret)
|
|
|
|
goto out_put_group;
|
2014-07-03 19:51:18 +04:00
|
|
|
|
|
|
|
return group;
|
2020-04-29 16:36:39 +03:00
|
|
|
|
|
|
|
out_put_group:
|
|
|
|
iommu_group_put(group);
|
|
|
|
|
|
|
|
return ERR_PTR(ret);
|
2014-07-03 19:51:18 +04:00
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:35 +03:00
|
|
|
struct iommu_domain *iommu_group_default_domain(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
return group->default_domain;
|
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:49 +03:00
|
|
|
static int probe_iommu_group(struct device *dev, void *data)
|
2011-10-21 23:56:05 +04:00
|
|
|
{
|
2020-04-29 16:36:49 +03:00
|
|
|
struct list_head *group_list = data;
|
2020-04-29 16:36:51 +03:00
|
|
|
struct iommu_group *group;
|
2020-04-29 16:36:49 +03:00
|
|
|
int ret;
|
2015-06-29 11:16:08 +03:00
|
|
|
|
2020-04-29 16:36:51 +03:00
|
|
|
/* Device is probed already if in a group */
|
|
|
|
group = iommu_group_get(dev);
|
|
|
|
if (group) {
|
|
|
|
iommu_group_put(group);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:49 +03:00
|
|
|
ret = __iommu_probe_device(dev, group_list);
|
2015-06-29 11:16:08 +03:00
|
|
|
if (ret == -ENODEV)
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
return ret;
|
2011-10-21 23:56:05 +04:00
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:27 +03:00
|
|
|
static int remove_iommu_group(struct device *dev, void *data)
|
|
|
|
{
|
2018-11-30 12:31:59 +03:00
|
|
|
iommu_release_device(dev);
|
2011-10-21 23:56:05 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static int iommu_bus_notifier(struct notifier_block *nb,
|
|
|
|
unsigned long action, void *data)
|
2011-10-21 23:56:05 +04:00
|
|
|
{
|
2018-11-30 12:31:59 +03:00
|
|
|
unsigned long group_action = 0;
|
2011-10-21 23:56:05 +04:00
|
|
|
struct device *dev = 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
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ADD/DEL call into iommu driver ops if provided, which may
|
|
|
|
* result in ADD/DEL notifiers to group->notifier
|
|
|
|
*/
|
|
|
|
if (action == BUS_NOTIFY_ADD_DEVICE) {
|
2018-11-30 12:31:59 +03:00
|
|
|
int ret;
|
2017-04-18 15:51:48 +03:00
|
|
|
|
2018-11-30 12:31:59 +03:00
|
|
|
ret = iommu_probe_device(dev);
|
|
|
|
return (ret) ? NOTIFY_DONE : NOTIFY_OK;
|
2015-05-28 19:41:28 +03:00
|
|
|
} else if (action == BUS_NOTIFY_REMOVED_DEVICE) {
|
2018-11-30 12:31:59 +03:00
|
|
|
iommu_release_device(dev);
|
|
|
|
return NOTIFY_OK;
|
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
|
|
|
}
|
2011-10-21 23:56:05 +04: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
|
|
|
/*
|
|
|
|
* Remaining BUS_NOTIFYs get filtered and republished to the
|
|
|
|
* group, if anyone is listening
|
|
|
|
*/
|
|
|
|
group = iommu_group_get(dev);
|
|
|
|
if (!group)
|
|
|
|
return 0;
|
2011-10-21 23:56:05 +04: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
|
|
|
switch (action) {
|
|
|
|
case BUS_NOTIFY_BIND_DRIVER:
|
|
|
|
group_action = IOMMU_GROUP_NOTIFY_BIND_DRIVER;
|
|
|
|
break;
|
|
|
|
case BUS_NOTIFY_BOUND_DRIVER:
|
|
|
|
group_action = IOMMU_GROUP_NOTIFY_BOUND_DRIVER;
|
|
|
|
break;
|
|
|
|
case BUS_NOTIFY_UNBIND_DRIVER:
|
|
|
|
group_action = IOMMU_GROUP_NOTIFY_UNBIND_DRIVER;
|
|
|
|
break;
|
|
|
|
case BUS_NOTIFY_UNBOUND_DRIVER:
|
|
|
|
group_action = IOMMU_GROUP_NOTIFY_UNBOUND_DRIVER;
|
|
|
|
break;
|
|
|
|
}
|
2011-10-21 23:56:05 +04: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
|
|
|
if (group_action)
|
|
|
|
blocking_notifier_call_chain(&group->notifier,
|
|
|
|
group_action, dev);
|
2011-10-21 23:56:05 +04: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
|
|
|
iommu_group_put(group);
|
2011-10-21 23:56:05 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:49 +03:00
|
|
|
struct __group_domain_type {
|
|
|
|
struct device *dev;
|
|
|
|
unsigned int type;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int probe_get_default_domain_type(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct __group_domain_type *gtype = data;
|
2020-11-24 16:06:01 +03:00
|
|
|
unsigned int type = iommu_get_def_domain_type(dev);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
|
|
|
if (type) {
|
|
|
|
if (gtype->type && gtype->type != type) {
|
|
|
|
dev_warn(dev, "Device needs domain type %s, but device %s in the same iommu group requires type %s - using default\n",
|
|
|
|
iommu_domain_type_str(type),
|
|
|
|
dev_name(gtype->dev),
|
|
|
|
iommu_domain_type_str(gtype->type));
|
|
|
|
gtype->type = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!gtype->dev) {
|
|
|
|
gtype->dev = dev;
|
|
|
|
gtype->type = type;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_alloc_default_domain(struct bus_type *bus,
|
|
|
|
struct iommu_group *group)
|
|
|
|
{
|
|
|
|
struct __group_domain_type gtype;
|
|
|
|
|
|
|
|
memset(>ype, 0, sizeof(gtype));
|
|
|
|
|
|
|
|
/* Ask for default domain requirements of all devices in the group */
|
|
|
|
__iommu_group_for_each_dev(group, >ype,
|
|
|
|
probe_get_default_domain_type);
|
|
|
|
|
|
|
|
if (!gtype.type)
|
|
|
|
gtype.type = iommu_def_domain_type;
|
|
|
|
|
|
|
|
iommu_group_alloc_default_domain(bus, group, gtype.type);
|
2020-04-29 16:36:50 +03:00
|
|
|
|
2020-04-29 16:36:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int iommu_group_do_dma_attach(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct iommu_domain *domain = data;
|
2020-06-04 12:19:44 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!iommu_is_attach_deferred(domain, dev))
|
|
|
|
ret = __iommu_attach_device(domain, dev);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-06-04 12:19:44 +03:00
|
|
|
return ret;
|
2020-04-29 16:36:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __iommu_group_dma_attach(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
return __iommu_group_for_each_dev(group, group->default_domain,
|
|
|
|
iommu_group_do_dma_attach);
|
|
|
|
}
|
|
|
|
|
2020-05-19 16:28:24 +03:00
|
|
|
static int iommu_group_do_probe_finalize(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct iommu_domain *domain = data;
|
|
|
|
|
|
|
|
if (domain->ops->probe_finalize)
|
|
|
|
domain->ops->probe_finalize(dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __iommu_group_dma_finalize(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
__iommu_group_for_each_dev(group, group->default_domain,
|
|
|
|
iommu_group_do_probe_finalize);
|
|
|
|
}
|
2020-06-02 11:32:04 +03:00
|
|
|
|
2020-04-29 16:36:50 +03:00
|
|
|
static int iommu_do_create_direct_mappings(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct iommu_group *group = data;
|
|
|
|
|
|
|
|
iommu_create_device_direct_mappings(group, dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iommu_group_create_direct_mappings(struct iommu_group *group)
|
|
|
|
{
|
|
|
|
return __iommu_group_for_each_dev(group, group,
|
|
|
|
iommu_do_create_direct_mappings);
|
|
|
|
}
|
|
|
|
|
2020-04-29 16:36:51 +03:00
|
|
|
int bus_iommu_probe(struct bus_type *bus)
|
2020-04-29 16:36:49 +03:00
|
|
|
{
|
2020-04-29 16:37:10 +03:00
|
|
|
struct iommu_group *group, *next;
|
|
|
|
LIST_HEAD(group_list);
|
2020-04-29 16:36:49 +03:00
|
|
|
int ret;
|
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
/*
|
|
|
|
* This code-path does not allocate the default domain when
|
|
|
|
* creating the iommu group, so do it after the groups are
|
|
|
|
* created.
|
|
|
|
*/
|
|
|
|
ret = bus_for_each_dev(bus, NULL, &group_list, probe_iommu_group);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
list_for_each_entry_safe(group, next, &group_list, entry) {
|
|
|
|
/* Remove item from the list */
|
|
|
|
list_del_init(&group->entry);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
mutex_lock(&group->mutex);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
/* Try to allocate default domain */
|
|
|
|
probe_alloc_default_domain(bus, group);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
if (!group->default_domain) {
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
continue;
|
|
|
|
}
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
iommu_group_create_direct_mappings(group);
|
2020-04-29 16:36:50 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
ret = __iommu_group_dma_attach(group);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
mutex_unlock(&group->mutex);
|
2020-04-29 16:36:49 +03:00
|
|
|
|
2020-04-29 16:37:10 +03:00
|
|
|
if (ret)
|
|
|
|
break;
|
2020-05-19 16:28:24 +03:00
|
|
|
|
|
|
|
__iommu_group_dma_finalize(group);
|
2020-04-29 16:36:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-09-21 21:58:24 +04:00
|
|
|
static int iommu_bus_init(struct bus_type *bus, const struct iommu_ops *ops)
|
2011-08-26 18:48:26 +04:00
|
|
|
{
|
2014-09-21 21:58:24 +04:00
|
|
|
struct notifier_block *nb;
|
2020-04-29 16:36:49 +03:00
|
|
|
int err;
|
2014-06-27 11:03:12 +04:00
|
|
|
|
2014-09-21 21:58:24 +04:00
|
|
|
nb = kzalloc(sizeof(struct notifier_block), GFP_KERNEL);
|
|
|
|
if (!nb)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
nb->notifier_call = iommu_bus_notifier;
|
|
|
|
|
|
|
|
err = bus_register_notifier(bus, nb);
|
2015-05-28 19:41:27 +03:00
|
|
|
if (err)
|
|
|
|
goto out_free;
|
2014-10-29 03:22:56 +03:00
|
|
|
|
2020-04-29 16:36:49 +03:00
|
|
|
err = bus_iommu_probe(bus);
|
2015-05-28 19:41:27 +03:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
2014-10-29 03:22:56 +03:00
|
|
|
|
|
|
|
return 0;
|
2015-05-28 19:41:27 +03:00
|
|
|
|
|
|
|
out_err:
|
|
|
|
/* Clean up */
|
2019-03-20 04:40:24 +03:00
|
|
|
bus_for_each_dev(bus, NULL, NULL, remove_iommu_group);
|
2015-05-28 19:41:27 +03:00
|
|
|
bus_unregister_notifier(bus, nb);
|
|
|
|
|
|
|
|
out_free:
|
|
|
|
kfree(nb);
|
|
|
|
|
|
|
|
return err;
|
2011-08-26 18:48:26 +04:00
|
|
|
}
|
2008-11-26 19:21:24 +03:00
|
|
|
|
2011-08-26 18:48:26 +04:00
|
|
|
/**
|
|
|
|
* bus_set_iommu - set iommu-callbacks for the bus
|
|
|
|
* @bus: bus.
|
|
|
|
* @ops: the callbacks provided by the iommu-driver
|
|
|
|
*
|
|
|
|
* This function is called by an iommu driver to set the iommu methods
|
|
|
|
* used for a particular bus. Drivers for devices on that bus can use
|
|
|
|
* the iommu-api after these ops are registered.
|
|
|
|
* This special function is needed because IOMMUs are usually devices on
|
|
|
|
* the bus itself, so the iommu drivers are not initialized when the bus
|
|
|
|
* is set up. With this function the iommu-driver can set the iommu-ops
|
|
|
|
* afterwards.
|
|
|
|
*/
|
2014-06-27 11:03:12 +04:00
|
|
|
int bus_set_iommu(struct bus_type *bus, const struct iommu_ops *ops)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
2014-10-29 03:22:56 +03:00
|
|
|
int err;
|
|
|
|
|
2019-12-19 15:03:43 +03:00
|
|
|
if (ops == NULL) {
|
|
|
|
bus->iommu_ops = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-26 18:48:26 +04:00
|
|
|
if (bus->iommu_ops != NULL)
|
|
|
|
return -EBUSY;
|
2008-11-26 19:21:24 +03:00
|
|
|
|
2011-08-26 18:48:26 +04:00
|
|
|
bus->iommu_ops = ops;
|
|
|
|
|
|
|
|
/* Do IOMMU specific setup for this bus-type */
|
2014-10-29 03:22:56 +03:00
|
|
|
err = iommu_bus_init(bus, ops);
|
|
|
|
if (err)
|
|
|
|
bus->iommu_ops = NULL;
|
|
|
|
|
|
|
|
return err;
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
2011-08-26 18:48:26 +04:00
|
|
|
EXPORT_SYMBOL_GPL(bus_set_iommu);
|
2008-11-26 19:21:24 +03:00
|
|
|
|
2011-09-06 20:46:34 +04:00
|
|
|
bool iommu_present(struct bus_type *bus)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
2011-09-06 20:58:54 +04:00
|
|
|
return bus->iommu_ops != NULL;
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
2011-09-06 20:46:34 +04:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_present);
|
2008-11-26 19:21:24 +03:00
|
|
|
|
2014-09-03 20:47:25 +04:00
|
|
|
bool iommu_capable(struct bus_type *bus, enum iommu_cap cap)
|
|
|
|
{
|
|
|
|
if (!bus->iommu_ops || !bus->iommu_ops->capable)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return bus->iommu_ops->capable(cap);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_capable);
|
|
|
|
|
2011-09-13 23:25:23 +04:00
|
|
|
/**
|
|
|
|
* iommu_set_fault_handler() - set a fault handler for an iommu domain
|
|
|
|
* @domain: iommu domain
|
|
|
|
* @handler: fault handler
|
2012-05-21 21:20:05 +04:00
|
|
|
* @token: user data, will be passed back to the fault handler
|
2011-09-27 15:36:40 +04:00
|
|
|
*
|
|
|
|
* This function should be used by IOMMU users which want to be notified
|
|
|
|
* whenever an IOMMU fault happens.
|
|
|
|
*
|
|
|
|
* The fault handler itself should return 0 on success, and an appropriate
|
|
|
|
* error code otherwise.
|
2011-09-13 23:25:23 +04:00
|
|
|
*/
|
|
|
|
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
|
|
|
{
|
|
|
|
BUG_ON(!domain);
|
|
|
|
|
|
|
|
domain->handler = handler;
|
2012-05-21 21:20:05 +04:00
|
|
|
domain->handler_token = token;
|
2011-09-13 23:25:23 +04:00
|
|
|
}
|
2011-09-26 17:11:46 +04:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_set_fault_handler);
|
2011-09-13 23:25:23 +04:00
|
|
|
|
2015-05-28 19:41:29 +03:00
|
|
|
static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
|
|
|
|
unsigned type)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
|
|
|
struct iommu_domain *domain;
|
|
|
|
|
2011-09-06 20:58:54 +04:00
|
|
|
if (bus == NULL || bus->iommu_ops == NULL)
|
2011-09-06 18:03:26 +04:00
|
|
|
return NULL;
|
|
|
|
|
2015-05-28 19:41:29 +03:00
|
|
|
domain = bus->iommu_ops->domain_alloc(type);
|
2008-11-26 19:21:24 +03:00
|
|
|
if (!domain)
|
|
|
|
return NULL;
|
|
|
|
|
2015-03-26 15:43:05 +03:00
|
|
|
domain->ops = bus->iommu_ops;
|
2015-05-28 19:41:29 +03:00
|
|
|
domain->type = type;
|
2016-04-07 20:42:06 +03:00
|
|
|
/* Assume all sizes by default; the driver may override this later */
|
|
|
|
domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap;
|
2011-09-06 18:03:26 +04:00
|
|
|
|
2021-09-13 15:40:06 +03:00
|
|
|
if (iommu_is_dma_domain(domain) && iommu_get_dma_cookie(domain)) {
|
2021-08-11 15:21:15 +03:00
|
|
|
iommu_domain_free(domain);
|
|
|
|
domain = NULL;
|
|
|
|
}
|
2008-11-26 19:21:24 +03:00
|
|
|
return domain;
|
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:29 +03:00
|
|
|
struct iommu_domain *iommu_domain_alloc(struct bus_type *bus)
|
|
|
|
{
|
|
|
|
return __iommu_domain_alloc(bus, IOMMU_DOMAIN_UNMANAGED);
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_domain_alloc);
|
|
|
|
|
|
|
|
void iommu_domain_free(struct iommu_domain *domain)
|
|
|
|
{
|
2021-08-11 15:21:15 +03:00
|
|
|
iommu_put_dma_cookie(domain);
|
2015-03-26 15:43:19 +03:00
|
|
|
domain->ops->domain_free(domain);
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_domain_free);
|
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
static int __iommu_attach_device(struct iommu_domain *domain,
|
|
|
|
struct device *dev)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
2013-08-15 21:59:26 +04:00
|
|
|
int ret;
|
2017-08-09 11:33:40 +03:00
|
|
|
|
2011-09-06 18:44:29 +04:00
|
|
|
if (unlikely(domain->ops->attach_dev == NULL))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-08-15 21:59:26 +04:00
|
|
|
ret = domain->ops->attach_dev(domain, dev);
|
|
|
|
if (!ret)
|
|
|
|
trace_attach_device_to_domain(dev);
|
|
|
|
return ret;
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
2015-05-28 19:41:30 +03:00
|
|
|
|
|
|
|
int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_group *group;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
2017-12-20 19:48:36 +03:00
|
|
|
if (!group)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
/*
|
2017-07-21 15:12:38 +03:00
|
|
|
* Lock the group to make sure the device-count doesn't
|
2015-05-28 19:41:30 +03:00
|
|
|
* change while we are attaching
|
|
|
|
*/
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
ret = -EINVAL;
|
|
|
|
if (iommu_group_device_count(group) != 1)
|
|
|
|
goto out_unlock;
|
|
|
|
|
2015-05-28 19:41:31 +03:00
|
|
|
ret = __iommu_attach_group(domain, group);
|
2015-05-28 19:41:30 +03:00
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
iommu_group_put(group);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2008-11-26 19:21:24 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_attach_device);
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = domain->ops;
|
|
|
|
|
|
|
|
if (ops->is_attach_deferred && ops->is_attach_deferred(domain, dev))
|
|
|
|
return __iommu_attach_device(domain, dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
/*
|
|
|
|
* Check flags and other user provided data for valid combinations. We also
|
|
|
|
* make sure no reserved fields or unused flags are set. This is to ensure
|
|
|
|
* not breaking userspace in the future when these fields or flags are used.
|
|
|
|
*/
|
|
|
|
static int iommu_check_cache_invl_data(struct iommu_cache_invalidate_info *info)
|
|
|
|
{
|
|
|
|
u32 mask;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mask = (1 << IOMMU_CACHE_INV_TYPE_NR) - 1;
|
|
|
|
if (info->cache & ~mask)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (info->granularity >= IOMMU_INV_GRANU_NR)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (info->granularity) {
|
|
|
|
case IOMMU_INV_GRANU_ADDR:
|
|
|
|
if (info->cache & IOMMU_CACHE_INV_TYPE_PASID)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mask = IOMMU_INV_ADDR_FLAGS_PASID |
|
|
|
|
IOMMU_INV_ADDR_FLAGS_ARCHID |
|
|
|
|
IOMMU_INV_ADDR_FLAGS_LEAF;
|
|
|
|
|
|
|
|
if (info->granu.addr_info.flags & ~mask)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
case IOMMU_INV_GRANU_PASID:
|
|
|
|
mask = IOMMU_INV_PASID_FLAGS_PASID |
|
|
|
|
IOMMU_INV_PASID_FLAGS_ARCHID;
|
|
|
|
if (info->granu.pasid_info.flags & ~mask)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
break;
|
|
|
|
case IOMMU_INV_GRANU_DOMAIN:
|
|
|
|
if (info->cache & IOMMU_CACHE_INV_TYPE_DEV_IOTLB)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check reserved padding fields */
|
|
|
|
for (i = 0; i < sizeof(info->padding); i++) {
|
|
|
|
if (info->padding[i])
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-09-25 19:32:45 +03:00
|
|
|
int iommu_uapi_cache_invalidate(struct iommu_domain *domain, struct device *dev,
|
2020-09-25 19:32:46 +03:00
|
|
|
void __user *uinfo)
|
2019-10-02 22:42:40 +03:00
|
|
|
{
|
2020-09-25 19:32:46 +03:00
|
|
|
struct iommu_cache_invalidate_info inv_info = { 0 };
|
|
|
|
u32 minsz;
|
|
|
|
int ret;
|
|
|
|
|
2019-10-02 22:42:40 +03:00
|
|
|
if (unlikely(!domain->ops->cache_invalidate))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
/*
|
|
|
|
* No new spaces can be added before the variable sized union, the
|
|
|
|
* minimum size is the offset to the union.
|
|
|
|
*/
|
|
|
|
minsz = offsetof(struct iommu_cache_invalidate_info, granu);
|
|
|
|
|
|
|
|
/* Copy minsz from user to get flags and argsz */
|
|
|
|
if (copy_from_user(&inv_info, uinfo, minsz))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
/* Fields before the variable size union are mandatory */
|
|
|
|
if (inv_info.argsz < minsz)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* PASID and address granu require additional info beyond minsz */
|
|
|
|
if (inv_info.granularity == IOMMU_INV_GRANU_PASID &&
|
|
|
|
inv_info.argsz < offsetofend(struct iommu_cache_invalidate_info, granu.pasid_info))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (inv_info.granularity == IOMMU_INV_GRANU_ADDR &&
|
|
|
|
inv_info.argsz < offsetofend(struct iommu_cache_invalidate_info, granu.addr_info))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* User might be using a newer UAPI header which has a larger data
|
|
|
|
* size, we shall support the existing flags within the current
|
|
|
|
* size. Copy the remaining user data _after_ minsz but not more
|
|
|
|
* than the current kernel supported size.
|
|
|
|
*/
|
|
|
|
if (copy_from_user((void *)&inv_info + minsz, uinfo + minsz,
|
|
|
|
min_t(u32, inv_info.argsz, sizeof(inv_info)) - minsz))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
/* Now the argsz is validated, check the content */
|
|
|
|
ret = iommu_check_cache_invl_data(&inv_info);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return domain->ops->cache_invalidate(domain, dev, &inv_info);
|
2019-10-02 22:42:40 +03:00
|
|
|
}
|
2020-09-25 19:32:45 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_uapi_cache_invalidate);
|
2019-10-02 22:42:40 +03:00
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
static int iommu_check_bind_data(struct iommu_gpasid_bind_data *data)
|
2019-10-02 22:42:43 +03:00
|
|
|
{
|
2020-11-03 13:16:23 +03:00
|
|
|
u64 mask;
|
2020-09-25 19:32:46 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (data->version != IOMMU_GPASID_BIND_VERSION_1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Check the range of supported formats */
|
|
|
|
if (data->format >= IOMMU_PASID_FORMAT_LAST)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Check all flags */
|
|
|
|
mask = IOMMU_SVA_GPASID_VAL;
|
|
|
|
if (data->flags & ~mask)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Check reserved padding fields */
|
|
|
|
for (i = 0; i < sizeof(data->padding); i++) {
|
|
|
|
if (data->padding[i])
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iommu_sva_prepare_bind_data(void __user *udata,
|
|
|
|
struct iommu_gpasid_bind_data *data)
|
|
|
|
{
|
|
|
|
u32 minsz;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No new spaces can be added before the variable sized union, the
|
|
|
|
* minimum size is the offset to the union.
|
|
|
|
*/
|
|
|
|
minsz = offsetof(struct iommu_gpasid_bind_data, vendor);
|
|
|
|
|
|
|
|
/* Copy minsz from user to get flags and argsz */
|
|
|
|
if (copy_from_user(data, udata, minsz))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
/* Fields before the variable size union are mandatory */
|
|
|
|
if (data->argsz < minsz)
|
|
|
|
return -EINVAL;
|
|
|
|
/*
|
|
|
|
* User might be using a newer UAPI header, we shall let IOMMU vendor
|
|
|
|
* driver decide on what size it needs. Since the guest PASID bind data
|
|
|
|
* can be vendor specific, larger argsz could be the result of extension
|
|
|
|
* for one vendor but it should not affect another vendor.
|
|
|
|
* Copy the remaining user data _after_ minsz
|
|
|
|
*/
|
|
|
|
if (copy_from_user((void *)data + minsz, udata + minsz,
|
|
|
|
min_t(u32, data->argsz, sizeof(*data)) - minsz))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return iommu_check_bind_data(data);
|
2019-10-02 22:42:40 +03:00
|
|
|
}
|
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
int iommu_uapi_sva_bind_gpasid(struct iommu_domain *domain, struct device *dev,
|
|
|
|
void __user *udata)
|
2019-10-02 22:42:43 +03:00
|
|
|
{
|
2020-09-25 19:32:46 +03:00
|
|
|
struct iommu_gpasid_bind_data data = { 0 };
|
|
|
|
int ret;
|
|
|
|
|
2019-10-02 22:42:43 +03:00
|
|
|
if (unlikely(!domain->ops->sva_bind_gpasid))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
ret = iommu_sva_prepare_bind_data(udata, &data);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return domain->ops->sva_bind_gpasid(domain, dev, &data);
|
2019-10-02 22:42:43 +03:00
|
|
|
}
|
2020-09-25 19:32:45 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_uapi_sva_bind_gpasid);
|
2019-10-02 22:42:43 +03:00
|
|
|
|
|
|
|
int iommu_sva_unbind_gpasid(struct iommu_domain *domain, struct device *dev,
|
|
|
|
ioasid_t pasid)
|
|
|
|
{
|
|
|
|
if (unlikely(!domain->ops->sva_unbind_gpasid))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
return domain->ops->sva_unbind_gpasid(dev, pasid);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_sva_unbind_gpasid);
|
|
|
|
|
2020-09-25 19:32:46 +03:00
|
|
|
int iommu_uapi_sva_unbind_gpasid(struct iommu_domain *domain, struct device *dev,
|
|
|
|
void __user *udata)
|
|
|
|
{
|
|
|
|
struct iommu_gpasid_bind_data data = { 0 };
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (unlikely(!domain->ops->sva_bind_gpasid))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ret = iommu_sva_prepare_bind_data(udata, &data);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return iommu_sva_unbind_gpasid(domain, dev, data.hpasid);
|
|
|
|
}
|
2020-09-25 19:32:45 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_uapi_sva_unbind_gpasid);
|
2019-10-02 22:42:43 +03:00
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
static void __iommu_detach_device(struct iommu_domain *domain,
|
|
|
|
struct device *dev)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
2020-05-19 16:03:40 +03:00
|
|
|
if (iommu_is_attach_deferred(domain, dev))
|
2017-08-09 11:33:40 +03:00
|
|
|
return;
|
|
|
|
|
2011-09-06 18:44:29 +04:00
|
|
|
if (unlikely(domain->ops->detach_dev == NULL))
|
|
|
|
return;
|
|
|
|
|
|
|
|
domain->ops->detach_dev(domain, dev);
|
2013-08-15 21:59:27 +04:00
|
|
|
trace_detach_device_from_domain(dev);
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
2015-05-28 19:41:30 +03:00
|
|
|
|
|
|
|
void iommu_detach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
2017-12-20 19:48:36 +03:00
|
|
|
if (!group)
|
|
|
|
return;
|
2015-05-28 19:41:30 +03:00
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
if (iommu_group_device_count(group) != 1) {
|
|
|
|
WARN_ON(1);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:31 +03:00
|
|
|
__iommu_detach_group(domain, group);
|
2015-05-28 19:41:30 +03:00
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
iommu_group_put(group);
|
|
|
|
}
|
2008-11-26 19:21:24 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_detach_device);
|
|
|
|
|
2015-05-28 19:41:32 +03:00
|
|
|
struct iommu_domain *iommu_get_domain_for_dev(struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_domain *domain;
|
|
|
|
struct iommu_group *group;
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
2017-08-17 13:40:08 +03:00
|
|
|
if (!group)
|
2015-05-28 19:41:32 +03:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
domain = group->domain;
|
|
|
|
|
|
|
|
iommu_group_put(group);
|
|
|
|
|
|
|
|
return domain;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_get_domain_for_dev);
|
2008-11-26 19:21:24 +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
|
|
|
/*
|
2018-09-12 18:24:12 +03:00
|
|
|
* For IOMMU_DOMAIN_DMA implementations which already provide their own
|
|
|
|
* guarantees that the group and its default domain are valid and correct.
|
|
|
|
*/
|
|
|
|
struct iommu_domain *iommu_get_dma_domain(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->iommu_group->default_domain;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
2018-09-18 17:38:49 +03:00
|
|
|
* IOMMU groups are really the natural working unit of the IOMMU, but
|
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
|
|
|
* the IOMMU API works on domains and devices. Bridge that gap by
|
|
|
|
* iterating over the devices in a group. Ideally we'd have a single
|
|
|
|
* device which represents the requestor ID of the group, but we also
|
|
|
|
* allow IOMMU drivers to create policy defined minimum sets, where
|
|
|
|
* the physical hardware may be able to distiguish members, but we
|
|
|
|
* wish to group them at a higher level (ex. untrusted multi-function
|
|
|
|
* PCI devices). Thus we attach each device.
|
|
|
|
*/
|
|
|
|
static int iommu_group_do_attach_device(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct iommu_domain *domain = data;
|
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
return __iommu_attach_device(domain, 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
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:31 +03:00
|
|
|
static int __iommu_attach_group(struct iommu_domain *domain,
|
|
|
|
struct iommu_group *group)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (group->default_domain && group->domain != group->default_domain)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
ret = __iommu_group_for_each_dev(group, domain,
|
|
|
|
iommu_group_do_attach_device);
|
|
|
|
if (ret == 0)
|
|
|
|
group->domain = domain;
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
int iommu_attach_group(struct iommu_domain *domain, struct iommu_group *group)
|
|
|
|
{
|
2015-05-28 19:41:31 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
ret = __iommu_attach_group(domain, group);
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_attach_group);
|
|
|
|
|
|
|
|
static int iommu_group_do_detach_device(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct iommu_domain *domain = data;
|
|
|
|
|
2015-05-28 19:41:30 +03:00
|
|
|
__iommu_detach_device(domain, 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 0;
|
|
|
|
}
|
|
|
|
|
2015-05-28 19:41:31 +03:00
|
|
|
static void __iommu_detach_group(struct iommu_domain *domain,
|
|
|
|
struct iommu_group *group)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!group->default_domain) {
|
|
|
|
__iommu_group_for_each_dev(group, domain,
|
|
|
|
iommu_group_do_detach_device);
|
|
|
|
group->domain = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (group->domain == group->default_domain)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Detach by re-attaching to the default domain */
|
|
|
|
ret = __iommu_group_for_each_dev(group, group->default_domain,
|
|
|
|
iommu_group_do_attach_device);
|
|
|
|
if (ret != 0)
|
|
|
|
WARN_ON(1);
|
|
|
|
else
|
|
|
|
group->domain = group->default_domain;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void iommu_detach_group(struct iommu_domain *domain, struct iommu_group *group)
|
|
|
|
{
|
2015-05-28 19:41:31 +03:00
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
__iommu_detach_group(domain, group);
|
|
|
|
mutex_unlock(&group->mutex);
|
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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_detach_group);
|
|
|
|
|
2013-03-28 23:53:58 +04:00
|
|
|
phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
|
2008-11-26 19:21:24 +03:00
|
|
|
{
|
2021-07-15 16:04:24 +03:00
|
|
|
if (domain->type == IOMMU_DOMAIN_IDENTITY)
|
|
|
|
return iova;
|
|
|
|
|
|
|
|
if (domain->type == IOMMU_DOMAIN_BLOCKED)
|
2011-09-06 18:44:29 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return domain->ops->iova_to_phys(domain, iova);
|
2008-11-26 19:21:24 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
|
2009-03-18 10:33:06 +03:00
|
|
|
|
2021-06-16 16:38:47 +03:00
|
|
|
static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
|
2021-06-16 16:38:48 +03:00
|
|
|
phys_addr_t paddr, size_t size, size_t *count)
|
2013-06-18 05:57:34 +04:00
|
|
|
{
|
2021-06-16 16:38:48 +03:00
|
|
|
unsigned int pgsize_idx, pgsize_idx_next;
|
2021-06-16 16:38:46 +03:00
|
|
|
unsigned long pgsizes;
|
2021-06-16 16:38:48 +03:00
|
|
|
size_t offset, pgsize, pgsize_next;
|
2021-06-16 16:38:47 +03:00
|
|
|
unsigned long addr_merge = paddr | iova;
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:46 +03:00
|
|
|
/* Page sizes supported by the hardware and small enough for @size */
|
|
|
|
pgsizes = domain->pgsize_bitmap & GENMASK(__fls(size), 0);
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:46 +03:00
|
|
|
/* Constrain the page sizes further based on the maximum alignment */
|
|
|
|
if (likely(addr_merge))
|
|
|
|
pgsizes &= GENMASK(__ffs(addr_merge), 0);
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:46 +03:00
|
|
|
/* Make sure we have at least one suitable page size */
|
|
|
|
BUG_ON(!pgsizes);
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:46 +03:00
|
|
|
/* Pick the biggest page size remaining */
|
|
|
|
pgsize_idx = __fls(pgsizes);
|
|
|
|
pgsize = BIT(pgsize_idx);
|
2021-06-16 16:38:48 +03:00
|
|
|
if (!count)
|
|
|
|
return pgsize;
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
/* Find the next biggest support page size, if it exists */
|
|
|
|
pgsizes = domain->pgsize_bitmap & ~GENMASK(pgsize_idx, 0);
|
|
|
|
if (!pgsizes)
|
|
|
|
goto out_set_count;
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
pgsize_idx_next = __ffs(pgsizes);
|
|
|
|
pgsize_next = BIT(pgsize_idx_next);
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
/*
|
|
|
|
* There's no point trying a bigger page size unless the virtual
|
|
|
|
* and physical addresses are similarly offset within the larger page.
|
|
|
|
*/
|
|
|
|
if ((iova ^ paddr) & (pgsize_next - 1))
|
|
|
|
goto out_set_count;
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
/* Calculate the offset to the next page size alignment boundary */
|
|
|
|
offset = pgsize_next - (addr_merge & (pgsize_next - 1));
|
2013-06-18 05:57:34 +04:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
/*
|
|
|
|
* If size is big enough to accommodate the larger page, reduce
|
|
|
|
* the number of smaller pages.
|
|
|
|
*/
|
|
|
|
if (offset + pgsize_next <= size)
|
|
|
|
size = offset;
|
|
|
|
|
|
|
|
out_set_count:
|
|
|
|
*count = size >> pgsize_idx;
|
2013-06-18 05:57:34 +04:00
|
|
|
return pgsize;
|
|
|
|
}
|
|
|
|
|
2021-06-16 16:38:49 +03:00
|
|
|
static int __iommu_map_pages(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
phys_addr_t paddr, size_t size, int prot,
|
|
|
|
gfp_t gfp, size_t *mapped)
|
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = domain->ops;
|
|
|
|
size_t pgsize, count;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
pgsize = iommu_pgsize(domain, iova, paddr, size, &count);
|
|
|
|
|
|
|
|
pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx count %zu\n",
|
|
|
|
iova, &paddr, pgsize, count);
|
|
|
|
|
|
|
|
if (ops->map_pages) {
|
|
|
|
ret = ops->map_pages(domain, iova, paddr, pgsize, count, prot,
|
|
|
|
gfp, mapped);
|
|
|
|
} else {
|
|
|
|
ret = ops->map(domain, iova, paddr, pgsize, prot, gfp);
|
|
|
|
*mapped = ret ? 0 : pgsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-07-13 17:25:42 +03:00
|
|
|
static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
|
2010-01-08 15:35:09 +03:00
|
|
|
{
|
2018-12-12 23:38:47 +03:00
|
|
|
const struct iommu_ops *ops = domain->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
|
|
|
unsigned long orig_iova = iova;
|
|
|
|
unsigned int min_pagesz;
|
|
|
|
size_t orig_size = size;
|
2016-02-10 04:18:04 +03:00
|
|
|
phys_addr_t orig_paddr = paddr;
|
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
|
|
|
int ret = 0;
|
2010-01-08 15:35:09 +03:00
|
|
|
|
2021-06-16 16:38:49 +03:00
|
|
|
if (unlikely(!(ops->map || ops->map_pages) ||
|
2016-04-07 20:42:06 +03:00
|
|
|
domain->pgsize_bitmap == 0UL))
|
2011-09-06 18:44:29 +04:00
|
|
|
return -ENODEV;
|
2010-01-08 15:35:09 +03:00
|
|
|
|
2015-03-26 15:43:06 +03:00
|
|
|
if (unlikely(!(domain->type & __IOMMU_DOMAIN_PAGING)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
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
|
|
|
/* find out the minimum page size supported */
|
2016-04-07 20:42:06 +03:00
|
|
|
min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* both the virtual address and the physical one, as well as
|
|
|
|
* the size of the mapping, must be aligned (at least) to the
|
|
|
|
* size of the smallest page supported by the hardware
|
|
|
|
*/
|
|
|
|
if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
|
2013-08-22 17:25:42 +04:00
|
|
|
pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 0x%x\n",
|
2013-06-23 23:29:04 +04:00
|
|
|
iova, &paddr, size, min_pagesz);
|
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
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-08-22 17:25:42 +04:00
|
|
|
pr_debug("map: iova 0x%lx pa %pa size 0x%zx\n", iova, &paddr, size);
|
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
|
|
|
|
|
|
|
while (size) {
|
2021-06-16 16:38:49 +03:00
|
|
|
size_t mapped = 0;
|
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
|
|
|
|
2021-06-16 16:38:49 +03:00
|
|
|
ret = __iommu_map_pages(domain, iova, paddr, size, prot, gfp,
|
|
|
|
&mapped);
|
|
|
|
/*
|
|
|
|
* Some pages may have been mapped, even if an error occurred,
|
|
|
|
* so we should account for those so they can be unmapped.
|
|
|
|
*/
|
|
|
|
size -= mapped;
|
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
|
|
|
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
|
2021-06-16 16:38:49 +03:00
|
|
|
iova += mapped;
|
|
|
|
paddr += mapped;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/* unroll mapping in case something went wrong */
|
|
|
|
if (ret)
|
|
|
|
iommu_unmap(domain, orig_iova, orig_size - size);
|
2013-08-15 21:59:28 +04:00
|
|
|
else
|
2016-02-10 04:18:04 +03:00
|
|
|
trace_map(orig_iova, orig_paddr, orig_size);
|
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
|
|
|
|
|
|
|
return ret;
|
2010-01-08 15:35:09 +03:00
|
|
|
}
|
2019-09-08 19:56:38 +03:00
|
|
|
|
2021-01-07 15:29:03 +03:00
|
|
|
static int _iommu_map(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
|
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = domain->ops;
|
|
|
|
int ret;
|
|
|
|
|
2021-02-02 04:06:23 +03:00
|
|
|
ret = __iommu_map(domain, iova, paddr, size, prot, gfp);
|
2021-01-07 15:29:03 +03:00
|
|
|
if (ret == 0 && ops->iotlb_sync_map)
|
2021-01-07 15:29:04 +03:00
|
|
|
ops->iotlb_sync_map(domain, iova, size);
|
2021-01-07 15:29:03 +03:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-09-08 19:56:38 +03:00
|
|
|
int iommu_map(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
phys_addr_t paddr, size_t size, int prot)
|
|
|
|
{
|
|
|
|
might_sleep();
|
2021-01-07 15:29:03 +03:00
|
|
|
return _iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
|
2019-09-08 19:56:38 +03:00
|
|
|
}
|
2010-01-08 15:35:09 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_map);
|
|
|
|
|
2019-09-08 19:56:38 +03:00
|
|
|
int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
phys_addr_t paddr, size_t size, int prot)
|
|
|
|
{
|
2021-01-07 15:29:03 +03:00
|
|
|
return _iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
|
2019-09-08 19:56:38 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_map_atomic);
|
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
static size_t __iommu_unmap_pages(struct iommu_domain *domain,
|
|
|
|
unsigned long iova, size_t size,
|
|
|
|
struct iommu_iotlb_gather *iotlb_gather)
|
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = domain->ops;
|
|
|
|
size_t pgsize, count;
|
|
|
|
|
|
|
|
pgsize = iommu_pgsize(domain, iova, iova, size, &count);
|
|
|
|
return ops->unmap_pages ?
|
|
|
|
ops->unmap_pages(domain, iova, pgsize, count, iotlb_gather) :
|
|
|
|
ops->unmap(domain, iova, pgsize, iotlb_gather);
|
|
|
|
}
|
|
|
|
|
2017-08-23 16:50:04 +03:00
|
|
|
static size_t __iommu_unmap(struct iommu_domain *domain,
|
|
|
|
unsigned long iova, size_t size,
|
2019-07-02 18:43:48 +03:00
|
|
|
struct iommu_iotlb_gather *iotlb_gather)
|
2010-01-08 15:35:09 +03:00
|
|
|
{
|
2017-08-23 16:50:04 +03:00
|
|
|
const struct iommu_ops *ops = domain->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
|
|
|
size_t unmapped_page, unmapped = 0;
|
2015-01-17 02:47:19 +03:00
|
|
|
unsigned long orig_iova = iova;
|
2017-08-23 16:50:04 +03:00
|
|
|
unsigned int min_pagesz;
|
2010-01-08 15:35:09 +03:00
|
|
|
|
2021-06-16 16:38:48 +03:00
|
|
|
if (unlikely(!(ops->unmap || ops->unmap_pages) ||
|
2016-04-07 20:42:06 +03:00
|
|
|
domain->pgsize_bitmap == 0UL))
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
2011-09-06 18:44:29 +04:00
|
|
|
|
2015-03-26 15:43:06 +03:00
|
|
|
if (unlikely(!(domain->type & __IOMMU_DOMAIN_PAGING)))
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
2015-03-26 15:43:06 +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
|
|
|
/* find out the minimum page size supported */
|
2016-04-07 20:42:06 +03:00
|
|
|
min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* The virtual address, as well as the size of the mapping, must be
|
|
|
|
* aligned (at least) to the size of the smallest page supported
|
|
|
|
* by the hardware
|
|
|
|
*/
|
|
|
|
if (!IS_ALIGNED(iova | size, min_pagesz)) {
|
2013-06-23 23:29:04 +04:00
|
|
|
pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
|
|
|
|
iova, size, min_pagesz);
|
2018-02-05 13:45:53 +03:00
|
|
|
return 0;
|
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
|
|
|
}
|
|
|
|
|
2013-06-23 23:29:04 +04:00
|
|
|
pr_debug("unmap this: iova 0x%lx size 0x%zx\n", iova, size);
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Keep iterating until we either unmap 'size' bytes (or more)
|
|
|
|
* or we hit an area that isn't mapped.
|
|
|
|
*/
|
|
|
|
while (unmapped < size) {
|
2021-06-16 16:38:48 +03:00
|
|
|
unmapped_page = __iommu_unmap_pages(domain, iova,
|
|
|
|
size - unmapped,
|
|
|
|
iotlb_gather);
|
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
|
|
|
if (!unmapped_page)
|
|
|
|
break;
|
|
|
|
|
2013-06-23 23:29:04 +04:00
|
|
|
pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
|
|
|
|
iova, unmapped_page);
|
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 += unmapped_page;
|
|
|
|
unmapped += unmapped_page;
|
|
|
|
}
|
|
|
|
|
2015-01-17 06:53:17 +03:00
|
|
|
trace_unmap(orig_iova, size, unmapped);
|
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
|
|
|
return unmapped;
|
2010-01-08 15:35:09 +03:00
|
|
|
}
|
2017-08-23 16:50:04 +03:00
|
|
|
|
|
|
|
size_t iommu_unmap(struct iommu_domain *domain,
|
|
|
|
unsigned long iova, size_t size)
|
|
|
|
{
|
2019-07-02 18:43:48 +03:00
|
|
|
struct iommu_iotlb_gather iotlb_gather;
|
|
|
|
size_t ret;
|
|
|
|
|
|
|
|
iommu_iotlb_gather_init(&iotlb_gather);
|
|
|
|
ret = __iommu_unmap(domain, iova, size, &iotlb_gather);
|
2020-08-18 00:00:49 +03:00
|
|
|
iommu_iotlb_sync(domain, &iotlb_gather);
|
2019-07-02 18:43:48 +03:00
|
|
|
|
|
|
|
return ret;
|
2017-08-23 16:50:04 +03:00
|
|
|
}
|
2010-01-08 15:35:09 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_unmap);
|
2011-10-21 23:56:05 +04:00
|
|
|
|
2017-08-23 16:50:04 +03:00
|
|
|
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)
|
2017-08-23 16:50:04 +03:00
|
|
|
{
|
2019-07-02 18:43:48 +03:00
|
|
|
return __iommu_unmap(domain, iova, size, iotlb_gather);
|
2017-08-23 16:50:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_unmap_fast);
|
|
|
|
|
2021-07-29 23:15:21 +03:00
|
|
|
static ssize_t __iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
|
|
|
|
struct scatterlist *sg, unsigned int nents, int prot,
|
|
|
|
gfp_t gfp)
|
2014-10-25 20:55:16 +04:00
|
|
|
{
|
2021-01-07 15:29:03 +03:00
|
|
|
const struct iommu_ops *ops = domain->ops;
|
2018-10-11 18:56:42 +03:00
|
|
|
size_t len = 0, mapped = 0;
|
|
|
|
phys_addr_t start;
|
|
|
|
unsigned int i = 0;
|
2014-11-04 16:53:51 +03:00
|
|
|
int ret;
|
2014-10-25 20:55:16 +04:00
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
while (i <= nents) {
|
|
|
|
phys_addr_t s_phys = sg_phys(sg);
|
2014-11-25 20:50:55 +03:00
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
if (len && s_phys != start + len) {
|
2019-09-08 19:56:38 +03:00
|
|
|
ret = __iommu_map(domain, iova + mapped, start,
|
|
|
|
len, prot, gfp);
|
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
if (ret)
|
|
|
|
goto out_err;
|
2014-11-25 20:50:55 +03:00
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
mapped += len;
|
|
|
|
len = 0;
|
|
|
|
}
|
2014-11-04 16:53:51 +03:00
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
if (len) {
|
|
|
|
len += sg->length;
|
|
|
|
} else {
|
|
|
|
len = sg->length;
|
|
|
|
start = s_phys;
|
|
|
|
}
|
2014-11-04 16:53:51 +03:00
|
|
|
|
2018-10-11 18:56:42 +03:00
|
|
|
if (++i < nents)
|
|
|
|
sg = sg_next(sg);
|
2014-10-25 20:55:16 +04:00
|
|
|
}
|
|
|
|
|
2021-01-07 15:29:03 +03:00
|
|
|
if (ops->iotlb_sync_map)
|
2021-01-07 15:29:04 +03:00
|
|
|
ops->iotlb_sync_map(domain, iova, mapped);
|
2014-10-25 20:55:16 +04:00
|
|
|
return mapped;
|
2014-11-04 16:53:51 +03:00
|
|
|
|
|
|
|
out_err:
|
|
|
|
/* undo mappings already done */
|
|
|
|
iommu_unmap(domain, iova, mapped);
|
|
|
|
|
2021-07-29 23:15:21 +03:00
|
|
|
return ret;
|
2014-10-25 20:55:16 +04:00
|
|
|
}
|
2019-09-08 19:56:38 +03:00
|
|
|
|
2021-07-29 23:15:21 +03:00
|
|
|
ssize_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
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
return __iommu_map_sg(domain, iova, sg, nents, prot, GFP_KERNEL);
|
|
|
|
}
|
2018-07-30 10:36:26 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_map_sg);
|
2013-01-29 17:26:20 +04:00
|
|
|
|
2021-07-29 23:15:21 +03:00
|
|
|
ssize_t iommu_map_sg_atomic(struct iommu_domain *domain, unsigned long iova,
|
2019-09-08 19:56:38 +03:00
|
|
|
struct scatterlist *sg, unsigned int nents, int prot)
|
|
|
|
{
|
|
|
|
return __iommu_map_sg(domain, iova, sg, nents, prot, GFP_ATOMIC);
|
|
|
|
}
|
|
|
|
|
2017-04-26 16:39:28 +03:00
|
|
|
/**
|
|
|
|
* report_iommu_fault() - report about an IOMMU fault to the IOMMU framework
|
|
|
|
* @domain: the iommu domain where the fault has happened
|
|
|
|
* @dev: the device where the fault has happened
|
|
|
|
* @iova: the faulting address
|
|
|
|
* @flags: mmu fault flags (e.g. IOMMU_FAULT_READ/IOMMU_FAULT_WRITE/...)
|
|
|
|
*
|
|
|
|
* This function should be called by the low-level IOMMU implementations
|
|
|
|
* whenever IOMMU faults happen, to allow high-level users, that are
|
|
|
|
* interested in such events, to know about them.
|
|
|
|
*
|
|
|
|
* This event may be useful for several possible use cases:
|
|
|
|
* - mere logging of the event
|
|
|
|
* - dynamic TLB/PTE loading
|
|
|
|
* - if restarting of the faulting device is required
|
|
|
|
*
|
|
|
|
* Returns 0 on success and an appropriate error code otherwise (if dynamic
|
|
|
|
* PTE/TLB loading will one day be supported, implementations will be able
|
|
|
|
* to tell whether it succeeded or not according to this return value).
|
|
|
|
*
|
|
|
|
* Specifically, -ENOSYS is returned if a fault handler isn't installed
|
|
|
|
* (though fault handlers can also return -ENOSYS, in case they want to
|
|
|
|
* elicit the default behavior of the IOMMU drivers).
|
|
|
|
*/
|
|
|
|
int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
|
|
|
|
unsigned long iova, int flags)
|
|
|
|
{
|
|
|
|
int ret = -ENOSYS;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* if upper layers showed interest and installed a fault handler,
|
|
|
|
* invoke it.
|
|
|
|
*/
|
|
|
|
if (domain->handler)
|
|
|
|
ret = domain->handler(domain, dev, iova, flags,
|
|
|
|
domain->handler_token);
|
|
|
|
|
|
|
|
trace_io_page_fault(dev, iova, flags);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(report_iommu_fault);
|
|
|
|
|
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
|
|
|
static int __init iommu_init(void)
|
2011-10-21 23:56:05 +04: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
|
|
|
iommu_group_kset = kset_create_and_add("iommu_groups",
|
|
|
|
NULL, kernel_kobj);
|
|
|
|
BUG_ON(!iommu_group_kset);
|
|
|
|
|
2018-06-13 00:41:21 +03:00
|
|
|
iommu_debugfs_setup();
|
|
|
|
|
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;
|
2011-10-21 23:56:05 +04:00
|
|
|
}
|
2015-05-19 16:20:23 +03:00
|
|
|
core_initcall(iommu_init);
|
2012-01-26 22:40:52 +04:00
|
|
|
|
2021-04-01 18:52:52 +03:00
|
|
|
int iommu_enable_nesting(struct iommu_domain *domain)
|
|
|
|
{
|
|
|
|
if (domain->type != IOMMU_DOMAIN_UNMANAGED)
|
|
|
|
return -EINVAL;
|
|
|
|
if (!domain->ops->enable_nesting)
|
|
|
|
return -EINVAL;
|
|
|
|
return domain->ops->enable_nesting(domain);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_enable_nesting);
|
|
|
|
|
2021-04-01 18:52:55 +03:00
|
|
|
int iommu_set_pgtable_quirks(struct iommu_domain *domain,
|
|
|
|
unsigned long quirk)
|
|
|
|
{
|
|
|
|
if (domain->type != IOMMU_DOMAIN_UNMANAGED)
|
|
|
|
return -EINVAL;
|
|
|
|
if (!domain->ops->set_pgtable_quirks)
|
|
|
|
return -EINVAL;
|
|
|
|
return domain->ops->set_pgtable_quirks(domain, quirk);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_set_pgtable_quirks);
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
void iommu_get_resv_regions(struct device *dev, struct list_head *list)
|
2015-05-28 19:41:33 +03:00
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
if (ops && ops->get_resv_regions)
|
|
|
|
ops->get_resv_regions(dev, list);
|
2015-05-28 19:41:33 +03:00
|
|
|
}
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
void iommu_put_resv_regions(struct device *dev, struct list_head *list)
|
2015-05-28 19:41:33 +03:00
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
|
|
|
|
2017-01-19 23:57:47 +03:00
|
|
|
if (ops && ops->put_resv_regions)
|
|
|
|
ops->put_resv_regions(dev, list);
|
2015-05-28 19:41:33 +03:00
|
|
|
}
|
2015-05-28 19:41:36 +03:00
|
|
|
|
2019-12-18 16:42:01 +03:00
|
|
|
/**
|
|
|
|
* generic_iommu_put_resv_regions - Reserved region driver helper
|
|
|
|
* @dev: device for which to free reserved regions
|
|
|
|
* @list: reserved region list for device
|
|
|
|
*
|
|
|
|
* IOMMU drivers can use this to implement their .put_resv_regions() callback
|
|
|
|
* for simple reservations. Memory allocated for each reserved region will be
|
|
|
|
* freed. If an IOMMU driver allocates additional resources per region, it is
|
|
|
|
* going to have to implement a custom callback.
|
|
|
|
*/
|
|
|
|
void generic_iommu_put_resv_regions(struct device *dev, struct list_head *list)
|
|
|
|
{
|
|
|
|
struct iommu_resv_region *entry, *next;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(entry, next, list, list)
|
|
|
|
kfree(entry);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(generic_iommu_put_resv_regions);
|
|
|
|
|
2017-01-19 23:57:49 +03:00
|
|
|
struct iommu_resv_region *iommu_alloc_resv_region(phys_addr_t start,
|
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
|
|
|
size_t length, int prot,
|
|
|
|
enum iommu_resv_type type)
|
2017-01-19 23:57:49 +03:00
|
|
|
{
|
|
|
|
struct iommu_resv_region *region;
|
|
|
|
|
|
|
|
region = kzalloc(sizeof(*region), GFP_KERNEL);
|
|
|
|
if (!region)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(®ion->list);
|
|
|
|
region->start = start;
|
|
|
|
region->length = length;
|
|
|
|
region->prot = prot;
|
|
|
|
region->type = type;
|
|
|
|
return region;
|
2015-05-28 19:41:33 +03:00
|
|
|
}
|
2019-12-19 15:03:37 +03:00
|
|
|
EXPORT_SYMBOL_GPL(iommu_alloc_resv_region);
|
2015-05-28 19:41:36 +03:00
|
|
|
|
2019-08-19 16:22:47 +03:00
|
|
|
void iommu_set_default_passthrough(bool cmd_line)
|
|
|
|
{
|
|
|
|
if (cmd_line)
|
2021-04-01 18:52:53 +03:00
|
|
|
iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API;
|
2019-08-19 16:22:47 +03:00
|
|
|
iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
|
|
|
|
}
|
|
|
|
|
|
|
|
void iommu_set_default_translated(bool cmd_line)
|
|
|
|
{
|
|
|
|
if (cmd_line)
|
2021-04-01 18:52:53 +03:00
|
|
|
iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API;
|
2019-08-19 16:22:47 +03:00
|
|
|
iommu_def_domain_type = IOMMU_DOMAIN_DMA;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool iommu_default_passthrough(void)
|
|
|
|
{
|
|
|
|
return iommu_def_domain_type == IOMMU_DOMAIN_IDENTITY;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_default_passthrough);
|
|
|
|
|
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
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = NULL;
|
2017-02-02 14:19:12 +03:00
|
|
|
struct iommu_device *iommu;
|
2016-11-21 13:01:36 +03:00
|
|
|
|
2017-02-02 14:19:12 +03:00
|
|
|
spin_lock(&iommu_device_lock);
|
|
|
|
list_for_each_entry(iommu, &iommu_device_list, list)
|
|
|
|
if (iommu->fwnode == fwnode) {
|
|
|
|
ops = iommu->ops;
|
2016-11-21 13:01:36 +03:00
|
|
|
break;
|
|
|
|
}
|
2017-02-02 14:19:12 +03:00
|
|
|
spin_unlock(&iommu_device_lock);
|
2016-11-21 13:01:36 +03:00
|
|
|
return ops;
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2018-11-28 15:35:24 +03:00
|
|
|
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
|
2016-09-13 12:54:14 +03:00
|
|
|
|
|
|
|
if (fwspec)
|
|
|
|
return ops == fwspec->ops ? 0 : -EINVAL;
|
|
|
|
|
2020-03-26 18:08:31 +03:00
|
|
|
if (!dev_iommu_get(dev))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2020-02-13 17:00:21 +03:00
|
|
|
/* Preallocate for the overwhelmingly common case of 1 ID */
|
|
|
|
fwspec = kzalloc(struct_size(fwspec, ids, 1), GFP_KERNEL);
|
2016-09-13 12:54:14 +03:00
|
|
|
if (!fwspec)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
of_node_get(to_of_node(iommu_fwnode));
|
|
|
|
fwspec->iommu_fwnode = iommu_fwnode;
|
|
|
|
fwspec->ops = ops;
|
2018-11-28 15:35:24 +03:00
|
|
|
dev_iommu_fwspec_set(dev, fwspec);
|
2016-09-13 12:54:14 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_fwspec_init);
|
|
|
|
|
|
|
|
void iommu_fwspec_free(struct device *dev)
|
|
|
|
{
|
2018-11-28 15:35:24 +03:00
|
|
|
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
|
2016-09-13 12:54:14 +03:00
|
|
|
|
|
|
|
if (fwspec) {
|
|
|
|
fwnode_handle_put(fwspec->iommu_fwnode);
|
|
|
|
kfree(fwspec);
|
2018-11-28 15:35:24 +03:00
|
|
|
dev_iommu_fwspec_set(dev, NULL);
|
2016-09-13 12:54:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_fwspec_free);
|
|
|
|
|
|
|
|
int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
|
|
|
|
{
|
2018-11-28 15:35:24 +03:00
|
|
|
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
|
2020-02-13 17:00:21 +03:00
|
|
|
int i, new_num;
|
2016-09-13 12:54:14 +03:00
|
|
|
|
|
|
|
if (!fwspec)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2020-02-13 17:00:21 +03:00
|
|
|
new_num = fwspec->num_ids + num_ids;
|
|
|
|
if (new_num > 1) {
|
|
|
|
fwspec = krealloc(fwspec, struct_size(fwspec, ids, new_num),
|
|
|
|
GFP_KERNEL);
|
2016-09-13 12:54:14 +03:00
|
|
|
if (!fwspec)
|
|
|
|
return -ENOMEM;
|
2017-02-03 12:35:02 +03:00
|
|
|
|
2018-11-28 15:35:24 +03:00
|
|
|
dev_iommu_fwspec_set(dev, fwspec);
|
2016-09-13 12:54:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < num_ids; i++)
|
|
|
|
fwspec->ids[fwspec->num_ids + i] = ids[i];
|
|
|
|
|
2020-02-13 17:00:21 +03:00
|
|
|
fwspec->num_ids = new_num;
|
2016-09-13 12:54:14 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids);
|
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.
|
|
|
|
*/
|
|
|
|
int iommu_dev_enable_feature(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
{
|
2021-03-03 20:36:11 +03:00
|
|
|
if (dev->iommu && dev->iommu->iommu_dev) {
|
|
|
|
const struct iommu_ops *ops = dev->iommu->iommu_dev->ops;
|
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
|
|
|
|
2021-03-03 20:36:11 +03:00
|
|
|
if (ops->dev_enable_feat)
|
|
|
|
return ops->dev_enable_feat(dev, feat);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_dev_enable_feature);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The device drivers should do the necessary cleanups before calling this.
|
|
|
|
* For example, before disabling the aux-domain feature, the device driver
|
|
|
|
* should detach all aux-domains. Otherwise, this will return -EBUSY.
|
|
|
|
*/
|
|
|
|
int iommu_dev_disable_feature(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
{
|
2021-03-03 20:36:11 +03:00
|
|
|
if (dev->iommu && dev->iommu->iommu_dev) {
|
|
|
|
const struct iommu_ops *ops = dev->iommu->iommu_dev->ops;
|
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
|
|
|
|
2021-03-03 20:36:11 +03:00
|
|
|
if (ops->dev_disable_feat)
|
|
|
|
return ops->dev_disable_feat(dev, feat);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_dev_disable_feature);
|
|
|
|
|
|
|
|
bool iommu_dev_feature_enabled(struct device *dev, enum iommu_dev_features feat)
|
|
|
|
{
|
2021-03-03 20:36:11 +03:00
|
|
|
if (dev->iommu && dev->iommu->iommu_dev) {
|
|
|
|
const struct iommu_ops *ops = dev->iommu->iommu_dev->ops;
|
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
|
|
|
|
2021-03-03 20:36:11 +03:00
|
|
|
if (ops->dev_feat_enabled)
|
|
|
|
return ops->dev_feat_enabled(dev, feat);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_dev_feature_enabled);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Aux-domain specific attach/detach.
|
|
|
|
*
|
|
|
|
* Only works if iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX) returns
|
|
|
|
* true. Also, as long as domains are attached to a device through this
|
|
|
|
* interface, any tries to call iommu_attach_device() should fail
|
|
|
|
* (iommu_detach_device() can't fail, so we fail when trying to re-attach).
|
|
|
|
* This should make us safe against a device being attached to a guest as a
|
|
|
|
* whole while there are still pasid users on it (aux and sva).
|
|
|
|
*/
|
|
|
|
int iommu_aux_attach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
{
|
|
|
|
int ret = -ENODEV;
|
|
|
|
|
|
|
|
if (domain->ops->aux_attach_dev)
|
|
|
|
ret = domain->ops->aux_attach_dev(domain, dev);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
trace_attach_device_to_domain(dev);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_aux_attach_device);
|
|
|
|
|
|
|
|
void iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev)
|
|
|
|
{
|
|
|
|
if (domain->ops->aux_detach_dev) {
|
|
|
|
domain->ops->aux_detach_dev(domain, dev);
|
|
|
|
trace_detach_device_from_domain(dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_aux_detach_device);
|
|
|
|
|
|
|
|
int iommu_aux_get_pasid(struct iommu_domain *domain, struct device *dev)
|
|
|
|
{
|
|
|
|
int ret = -ENODEV;
|
|
|
|
|
|
|
|
if (domain->ops->aux_get_pasid)
|
|
|
|
ret = domain->ops->aux_get_pasid(domain, dev);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_sva_bind_device() - Bind a process address space to a device
|
|
|
|
* @dev: the device
|
|
|
|
* @mm: the mm to bind, caller must hold a reference to it
|
|
|
|
*
|
|
|
|
* Create a bond between device and address space, allowing the device to access
|
|
|
|
* the mm using the returned PASID. If a bond already exists between @device and
|
|
|
|
* @mm, it is returned and an additional reference is taken. Caller must call
|
|
|
|
* iommu_sva_unbind_device() to release each reference.
|
|
|
|
*
|
|
|
|
* iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) must be called first, to
|
|
|
|
* initialize the required SVA features.
|
|
|
|
*
|
|
|
|
* On error, returns an ERR_PTR value.
|
|
|
|
*/
|
|
|
|
struct iommu_sva *
|
|
|
|
iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata)
|
|
|
|
{
|
|
|
|
struct iommu_group *group;
|
|
|
|
struct iommu_sva *handle = ERR_PTR(-EINVAL);
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
|
|
|
|
|
|
|
if (!ops || !ops->sva_bind)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
|
|
|
if (!group)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
/* Ensure device count and domain don't change while we're binding */
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To keep things simple, SVA currently doesn't support IOMMU groups
|
|
|
|
* with more than one device. Existing SVA-capable systems are not
|
|
|
|
* affected by the problems that required IOMMU groups (lack of ACS
|
|
|
|
* isolation, device ID aliasing and other hardware issues).
|
|
|
|
*/
|
|
|
|
if (iommu_group_device_count(group) != 1)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
handle = ops->sva_bind(dev, mm, drvdata);
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
iommu_group_put(group);
|
|
|
|
|
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device
|
|
|
|
* @handle: the handle returned by iommu_sva_bind_device()
|
|
|
|
*
|
|
|
|
* Put reference to a bond between device and address space. The device should
|
|
|
|
* not be issuing any more transaction for this PASID. All outstanding page
|
|
|
|
* requests for this PASID must have been flushed to the IOMMU.
|
|
|
|
*/
|
|
|
|
void iommu_sva_unbind_device(struct iommu_sva *handle)
|
|
|
|
{
|
|
|
|
struct iommu_group *group;
|
|
|
|
struct device *dev = handle->dev;
|
|
|
|
const struct iommu_ops *ops = dev->bus->iommu_ops;
|
|
|
|
|
|
|
|
if (!ops || !ops->sva_unbind)
|
|
|
|
return;
|
|
|
|
|
|
|
|
group = iommu_group_get(dev);
|
|
|
|
if (!group)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
ops->sva_unbind(handle);
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
iommu_group_put(group);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
|
|
|
|
|
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
|
|
|
{
|
|
|
|
const struct iommu_ops *ops = handle->dev->bus->iommu_ops;
|
|
|
|
|
|
|
|
if (!ops || !ops->sva_get_pasid)
|
|
|
|
return IOMMU_PASID_INVALID;
|
|
|
|
|
|
|
|
return ops->sva_get_pasid(handle);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
|
2020-11-24 16:06:02 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Changes the default domain of an iommu group that has *only* one device
|
|
|
|
*
|
|
|
|
* @group: The group for which the default domain should be changed
|
|
|
|
* @prev_dev: The device in the group (this is used to make sure that the device
|
|
|
|
* hasn't changed after the caller has called this function)
|
|
|
|
* @type: The type of the new default domain that gets associated with the group
|
|
|
|
*
|
|
|
|
* Returns 0 on success and error code on failure
|
|
|
|
*
|
|
|
|
* Note:
|
|
|
|
* 1. Presently, this function is called only when user requests to change the
|
|
|
|
* group's default domain type through /sys/kernel/iommu_groups/<grp_id>/type
|
|
|
|
* Please take a closer look if intended to use for other purposes.
|
|
|
|
*/
|
|
|
|
static int iommu_change_dev_def_domain(struct iommu_group *group,
|
|
|
|
struct device *prev_dev, int type)
|
|
|
|
{
|
|
|
|
struct iommu_domain *prev_dom;
|
|
|
|
struct group_device *grp_dev;
|
|
|
|
int ret, dev_def_dom;
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
|
|
|
|
if (group->default_domain != group->domain) {
|
|
|
|
dev_err_ratelimited(prev_dev, "Group not assigned to default domain\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* iommu group wasn't locked while acquiring device lock in
|
|
|
|
* iommu_group_store_type(). So, make sure that the device count hasn't
|
|
|
|
* changed while acquiring device lock.
|
|
|
|
*
|
|
|
|
* Changing default domain of an iommu group with two or more devices
|
|
|
|
* isn't supported because there could be a potential deadlock. Consider
|
|
|
|
* the following scenario. T1 is trying to acquire device locks of all
|
|
|
|
* the devices in the group and before it could acquire all of them,
|
|
|
|
* there could be another thread T2 (from different sub-system and use
|
|
|
|
* case) that has already acquired some of the device locks and might be
|
|
|
|
* waiting for T1 to release other device locks.
|
|
|
|
*/
|
|
|
|
if (iommu_group_device_count(group) != 1) {
|
|
|
|
dev_err_ratelimited(prev_dev, "Cannot change default domain: Group has more than one device\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Since group has only one device */
|
|
|
|
grp_dev = list_first_entry(&group->devices, struct group_device, list);
|
|
|
|
dev = grp_dev->dev;
|
|
|
|
|
|
|
|
if (prev_dev != dev) {
|
|
|
|
dev_err_ratelimited(prev_dev, "Cannot change default domain: Device has been changed\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
prev_dom = group->default_domain;
|
|
|
|
if (!prev_dom) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_def_dom = iommu_get_def_domain_type(dev);
|
|
|
|
if (!type) {
|
|
|
|
/*
|
|
|
|
* If the user hasn't requested any specific type of domain and
|
|
|
|
* if the device supports both the domains, then default to the
|
|
|
|
* domain the device was booted with
|
|
|
|
*/
|
|
|
|
type = dev_def_dom ? : iommu_def_domain_type;
|
|
|
|
} else if (dev_def_dom && type != dev_def_dom) {
|
|
|
|
dev_err_ratelimited(prev_dev, "Device cannot be in %s domain\n",
|
|
|
|
iommu_domain_type_str(type));
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch to a new domain only if the requested domain type is different
|
|
|
|
* from the existing default domain type
|
|
|
|
*/
|
|
|
|
if (prev_dom->type == type) {
|
|
|
|
ret = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-08-11 15:21:38 +03:00
|
|
|
/* We can bring up a flush queue without tearing down the domain */
|
|
|
|
if (type == IOMMU_DOMAIN_DMA_FQ && prev_dom->type == IOMMU_DOMAIN_DMA) {
|
|
|
|
ret = iommu_dma_init_fq(prev_dom);
|
|
|
|
if (!ret)
|
|
|
|
prev_dom->type = IOMMU_DOMAIN_DMA_FQ;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2020-11-24 16:06:02 +03:00
|
|
|
/* Sets group->default_domain to the newly allocated domain */
|
|
|
|
ret = iommu_group_alloc_default_domain(dev->bus, group, type);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ret = iommu_create_device_direct_mappings(group, dev);
|
|
|
|
if (ret)
|
|
|
|
goto free_new_domain;
|
|
|
|
|
|
|
|
ret = __iommu_attach_device(group->default_domain, dev);
|
|
|
|
if (ret)
|
|
|
|
goto free_new_domain;
|
|
|
|
|
|
|
|
group->domain = group->default_domain;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Release the mutex here because ops->probe_finalize() call-back of
|
|
|
|
* some vendor IOMMU drivers calls arm_iommu_attach_device() which
|
|
|
|
* in-turn might call back into IOMMU core code, where it tries to take
|
|
|
|
* group->mutex, resulting in a deadlock.
|
|
|
|
*/
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
/* Make sure dma_ops is appropriatley set */
|
|
|
|
iommu_group_do_probe_finalize(dev, group->default_domain);
|
|
|
|
iommu_domain_free(prev_dom);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
free_new_domain:
|
|
|
|
iommu_domain_free(group->default_domain);
|
|
|
|
group->default_domain = prev_dom;
|
|
|
|
group->domain = prev_dom;
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2021-08-11 15:21:38 +03:00
|
|
|
* Changing the default domain through sysfs requires the users to unbind the
|
|
|
|
* drivers from the devices in the iommu group, except for a DMA -> DMA-FQ
|
|
|
|
* transition. Return failure if this isn't met.
|
2020-11-24 16:06:02 +03:00
|
|
|
*
|
|
|
|
* We need to consider the race between this and the device release path.
|
|
|
|
* device_lock(dev) is used here to guarantee that the device release path
|
|
|
|
* will not be entered at the same time.
|
|
|
|
*/
|
|
|
|
static ssize_t iommu_group_store_type(struct iommu_group *group,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct group_device *grp_dev;
|
|
|
|
struct device *dev;
|
|
|
|
int ret, req_type;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
|
|
|
|
return -EACCES;
|
|
|
|
|
|
|
|
if (WARN_ON(!group))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (sysfs_streq(buf, "identity"))
|
|
|
|
req_type = IOMMU_DOMAIN_IDENTITY;
|
|
|
|
else if (sysfs_streq(buf, "DMA"))
|
|
|
|
req_type = IOMMU_DOMAIN_DMA;
|
2021-08-11 15:21:35 +03:00
|
|
|
else if (sysfs_streq(buf, "DMA-FQ"))
|
|
|
|
req_type = IOMMU_DOMAIN_DMA_FQ;
|
2020-11-24 16:06:02 +03:00
|
|
|
else if (sysfs_streq(buf, "auto"))
|
|
|
|
req_type = 0;
|
|
|
|
else
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock/Unlock the group mutex here before device lock to
|
|
|
|
* 1. Make sure that the iommu group has only one device (this is a
|
|
|
|
* prerequisite for step 2)
|
|
|
|
* 2. Get struct *dev which is needed to lock device
|
|
|
|
*/
|
|
|
|
mutex_lock(&group->mutex);
|
|
|
|
if (iommu_group_device_count(group) != 1) {
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
pr_err_ratelimited("Cannot change default domain: Group has more than one device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Since group has only one device */
|
|
|
|
grp_dev = list_first_entry(&group->devices, struct group_device, list);
|
|
|
|
dev = grp_dev->dev;
|
|
|
|
get_device(dev);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't hold the group mutex because taking group mutex first and then
|
|
|
|
* the device lock could potentially cause a deadlock as below. Assume
|
|
|
|
* two threads T1 and T2. T1 is trying to change default domain of an
|
|
|
|
* iommu group and T2 is trying to hot unplug a device or release [1] VF
|
|
|
|
* of a PCIe device which is in the same iommu group. T1 takes group
|
|
|
|
* mutex and before it could take device lock assume T2 has taken device
|
|
|
|
* lock and is yet to take group mutex. Now, both the threads will be
|
|
|
|
* waiting for the other thread to release lock. Below, lock order was
|
|
|
|
* suggested.
|
|
|
|
* device_lock(dev);
|
|
|
|
* mutex_lock(&group->mutex);
|
|
|
|
* iommu_change_dev_def_domain();
|
|
|
|
* mutex_unlock(&group->mutex);
|
|
|
|
* device_unlock(dev);
|
|
|
|
*
|
|
|
|
* [1] Typical device release path
|
|
|
|
* device_lock() from device/driver core code
|
|
|
|
* -> bus_notifier()
|
|
|
|
* -> iommu_bus_notifier()
|
|
|
|
* -> iommu_release_device()
|
|
|
|
* -> ops->release_device() vendor driver calls back iommu core code
|
|
|
|
* -> mutex_lock() from iommu core code
|
|
|
|
*/
|
|
|
|
mutex_unlock(&group->mutex);
|
|
|
|
|
|
|
|
/* Check if the device in the group still has a driver bound to it */
|
|
|
|
device_lock(dev);
|
2021-08-11 15:21:38 +03:00
|
|
|
if (device_is_bound(dev) && !(req_type == IOMMU_DOMAIN_DMA_FQ &&
|
|
|
|
group->default_domain->type == IOMMU_DOMAIN_DMA)) {
|
2020-11-24 16:06:02 +03:00
|
|
|
pr_err_ratelimited("Device is still bound to driver\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = iommu_change_dev_def_domain(group, dev, req_type);
|
|
|
|
ret = ret ?: count;
|
|
|
|
|
|
|
|
out:
|
|
|
|
device_unlock(dev);
|
|
|
|
put_device(dev);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|