| 1 | What: /sys/kernel/iommu_groups/ |
| 2 | Date: May 2012 |
| 3 | KernelVersion: v3.5 |
| 4 | Contact: Alex Williamson <[email protected]> |
| 5 | Description: /sys/kernel/iommu_groups/ contains a number of sub- |
| 6 | directories, each representing an IOMMU group. The |
| 7 | name of the sub-directory matches the iommu_group_id() |
| 8 | for the group, which is an integer value. Within each |
| 9 | subdirectory is another directory named "devices" with |
| 10 | links to the sysfs devices contained in this group. |
| 11 | The group directory also optionally contains a "name" |
| 12 | file if the IOMMU driver has chosen to register a more |
| 13 | common name for the group. |
| 14 | Users: |
| 15 | |
| 16 | What: /sys/kernel/iommu_groups/reserved_regions |
| 17 | Date: January 2017 |
| 18 | KernelVersion: v4.11 |
| 19 | Contact: Eric Auger <[email protected]> |
| 20 | Description: /sys/kernel/iommu_groups/reserved_regions list IOVA |
| 21 | regions that are reserved. Not necessarily all |
| 22 | reserved regions are listed. This is typically used to |
| 23 | output direct-mapped, MSI, non mappable regions. Each |
| 24 | region is described on a single line: the 1st field is |
| 25 | the base IOVA, the second is the end IOVA and the third |
| 26 | field describes the type of the region. |
| 27 | |
| 28 | Since kernel 5.3, in case an RMRR is used only by graphics or |
| 29 | USB devices it is now exposed as "direct-relaxable" instead |
| 30 | of "direct". In device assignment use case, for instance, |
| 31 | those RMRR are considered to be relaxable and safe. |
| 32 | |
| 33 | What: /sys/kernel/iommu_groups/<grp_id>/type |
| 34 | Date: November 2020 |
| 35 | KernelVersion: v5.11 |
| 36 | Contact: Sai Praneeth Prakhya <[email protected]> |
| 37 | Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default |
| 38 | domain in use by iommu for this group. See include/linux/iommu.h |
| 39 | for possible read values. A privileged user could request kernel to |
| 40 | change the group type by writing to this file. Valid write values: |
| 41 | |
| 42 | ======== ====================================================== |
| 43 | DMA All the DMA transactions from the device in this group |
| 44 | are translated by the iommu. |
| 45 | DMA-FQ As above, but using batched invalidation to lazily |
| 46 | remove translations after use. This may offer reduced |
| 47 | overhead at the cost of reduced memory protection. |
| 48 | identity All the DMA transactions from the device in this group |
| 49 | are not translated by the iommu. Maximum performance |
| 50 | but zero protection. |
| 51 | auto Change to the type the device was booted with. |
| 52 | ======== ====================================================== |
| 53 | |
| 54 | The default domain type of a group may be modified only when |
| 55 | |
| 56 | - The device in the group is not bound to any device driver. |
| 57 | So, the users must unbind the appropriate driver before |
| 58 | changing the default domain type. |
| 59 | |
| 60 | Unbinding a device driver will take away the driver's control |
| 61 | over the device and if done on devices that host root file |
| 62 | system could lead to catastrophic effects (the users might |
| 63 | need to reboot the machine to get it to normal state). So, it's |
| 64 | expected that the users understand what they're doing. |