26225bea1d
The sysfs interface for default domain types exists primarily so users can choose the performance/security tradeoff relevant to their own workload. As such, the choice between the policies for DMA domains fits perfectly as an additional point on that scale - downgrading a particular device from a strict default to non-strict may be enough to let it reach the desired level of performance, while still retaining more peace of mind than with a wide-open identity domain. Now that we've abstracted non-strict mode as a distinct type of DMA domain, allow it to be chosen through the user interface as well. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/0e08da5ed4069fd3473cfbadda758ca983becdbf.1628682049.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
3.0 KiB
What: /sys/kernel/iommu_groups/ Date: May 2012 KernelVersion: v3.5 Contact: Alex Williamson alex.williamson@redhat.com Description: /sys/kernel/iommu_groups/ contains a number of sub- directories, each representing an IOMMU group. The name of the sub-directory matches the iommu_group_id() for the group, which is an integer value. Within each subdirectory is another directory named "devices" with links to the sysfs devices contained in this group. The group directory also optionally contains a "name" file if the IOMMU driver has chosen to register a more common name for the group. Users:
What: /sys/kernel/iommu_groups/reserved_regions Date: January 2017 KernelVersion: v4.11 Contact: Eric Auger eric.auger@redhat.com Description: /sys/kernel/iommu_groups/reserved_regions list IOVA regions that are reserved. Not necessarily all reserved regions are listed. This is typically used to output direct-mapped, MSI, non mappable regions. Each region is described on a single line: the 1st field is the base IOVA, the second is the end IOVA and the third field describes the type of the region.
Since kernel 5.3, in case an RMRR is used only by graphics or
USB devices it is now exposed as "direct-relaxable" instead
of "direct". In device assignment use case, for instance,
those RMRR are considered to be relaxable and safe.
What: /sys/kernel/iommu_groups/<grp_id>/type Date: November 2020 KernelVersion: v5.11 Contact: Sai Praneeth Prakhya sai.praneeth.prakhya@intel.com Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default domain in use by iommu for this group. See include/linux/iommu.h for possible read values. A privileged user could request kernel to change the group type by writing to this file. Valid write values:
======== ======================================================
DMA All the DMA transactions from the device in this group
are translated by the iommu.
DMA-FQ As above, but using batched invalidation to lazily
remove translations after use. This may offer reduced
overhead at the cost of reduced memory protection.
identity All the DMA transactions from the device in this group
are not translated by the iommu. Maximum performance
but zero protection.
auto Change to the type the device was booted with.
======== ======================================================
The default domain type of a group may be modified only when
- The group has only one device.
- The device in the group is not bound to any device driver.
So, the users must unbind the appropriate driver before
changing the default domain type.
Unbinding a device driver will take away the driver's control
over the device and if done on devices that host root file
system could lead to catastrophic effects (the users might
need to reboot the machine to get it to normal state). So, it's
expected that the users understand what they're doing.