[PATCH] Documentation: x86: rework IOMMU documentation
Add preliminary documentation for AMD IOMMU and combine with the existing Intel IOMMU documentation and clean up and modernize some of the existing documentation to align with the current state of the kernel. Signed-off-by: Alex Deucher --- V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., a device) and document proper DMA API. Also correct the fact that the AMD IOMMU is not limited to managing PCI devices. v3: Fix spelling and rework text as suggested by Vasant v4: Combine Intel and AMD documents into a single document as suggested by Dave Hansen v5: Clarify that keywords are related to ACPI, grammatical fixes v6: Make more stuff common based on feedback from Robin Documentation/x86/index.rst | 2 +- Documentation/x86/intel-iommu.rst | 115 Documentation/x86/iommu.rst | 143 ++ 3 files changed, 144 insertions(+), 116 deletions(-) delete mode 100644 Documentation/x86/intel-iommu.rst create mode 100644 Documentation/x86/iommu.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..6f8409fe0674 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -21,7 +21,7 @@ x86-specific Documentation tlb mtrr pat - intel-iommu + iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst deleted file mode 100644 index 099f13d51d5f.. --- a/Documentation/x86/intel-iommu.rst +++ /dev/null @@ -1,115 +0,0 @@ -=== -Linux IOMMU Support -=== - -The architecture spec can be obtained from the below location. - -http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf - -This guide gives a quick cheat sheet for some basic understanding. - -Some Keywords - -- DMAR - DMA remapping -- DRHD - DMA Remapping Hardware Unit Definition -- RMRR - Reserved memory Region Reporting Structure -- ZLR - Zero length reads from PCI devices -- IOVA - IO Virtual address. - -Basic stuff - -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls -them. - -What is RMRR? -- - -There are some devices the BIOS controls, for e.g USB devices to perform -PS2 emulation. The regions of memory used for these devices are marked -reserved in the e820 map. When we turn on DMA translation, DMA to those -regions will fail. Hence BIOS uses RMRR to specify these regions along with -devices that need to access these regions. OS is expected to setup -unity mappings for these regions for these devices to access these regions. - -How is IOVA generated? --- - -Well behaved drivers call pci_map_*() calls before sending command to device -that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. - -The Intel IOMMU driver allocates a virtual address per domain. Each PCIE -device has its own domain (hence protection). Devices under p2p bridges -share the virtual address with all devices under the p2p bridge due to -transaction id aliasing for p2p bridges. - -IOVA generation is pretty generic. We used the same technique as vmalloc() -but these are not global address spaces, but separate for each domain. -Different DMA engines may support different number of domains. - -We also allocate guard pages with each mapping, so we can attempt to catch -any overflow that might happen. - - -Graphics Problems? --- -If you encounter issues with graphics devices, you can try adding -option intel_iommu=igfx_off to turn off the integrated graphics engine. -If this fixes anything, please ensure you file a bug reporting the problem. - -Some exceptions to IOVA -Interrupt ranges are not address translated, (0xfee0 - 0xfeef). -The same is true for peer to peer transactions. Hence we reserve the -address from PCI MMIO ranges so they are not allocated for IOVA addresses. - - -Fault reporting -When errors are reported, the DMA engine signals via an interrupt. The fault -reason and device that caused it with fault reason is printed on console. - -See below for sample. - - -Boot Message Sample - -Something like this gets printed indicating presence of DMAR tables -in ACPI. - -ACPI: DMAR (v001 A M I OEMDMAR 0x0001 MSFT 0x0097) @ 0x7f5b5ef0 - -When DMAR is being processed and initialized by ACPI, prints DMAR locations -and any RMRR's processed:: - - ACPI DMAR:Host address width 36 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed9 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed91000 - ACPI DMAR:DRHD (flags: 0x0001)base: 0xfed93000 - ACPI DMAR:RMRR base:
[PATCH v5] Documentation: x86: rework IOMMU documentation
Add preliminary documentation for AMD IOMMU and combine with the existing Intel IOMMU documentation and clean up and modernize some of the existing documentation to align with the current state of the kernel. Signed-off-by: Alex Deucher --- V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., a device) and document proper DMA API. Also correct the fact that the AMD IOMMU is not limited to managing PCI devices. v3: Fix spelling and rework text as suggested by Vasant v4: Combine Intel and AMD documents into a single document as suggested by Dave Hansen v5: Flag keywords as ACPI related. Some grammatical fixes. Documentation/x86/index.rst | 2 +- Documentation/x86/intel-iommu.rst | 115 --- Documentation/x86/iommu.rst | 151 ++ 3 files changed, 152 insertions(+), 116 deletions(-) delete mode 100644 Documentation/x86/intel-iommu.rst create mode 100644 Documentation/x86/iommu.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..6f8409fe0674 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -21,7 +21,7 @@ x86-specific Documentation tlb mtrr pat - intel-iommu + iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst deleted file mode 100644 index 099f13d51d5f.. --- a/Documentation/x86/intel-iommu.rst +++ /dev/null @@ -1,115 +0,0 @@ -=== -Linux IOMMU Support -=== - -The architecture spec can be obtained from the below location. - -http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf - -This guide gives a quick cheat sheet for some basic understanding. - -Some Keywords - -- DMAR - DMA remapping -- DRHD - DMA Remapping Hardware Unit Definition -- RMRR - Reserved memory Region Reporting Structure -- ZLR - Zero length reads from PCI devices -- IOVA - IO Virtual address. - -Basic stuff - -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls -them. - -What is RMRR? -- - -There are some devices the BIOS controls, for e.g USB devices to perform -PS2 emulation. The regions of memory used for these devices are marked -reserved in the e820 map. When we turn on DMA translation, DMA to those -regions will fail. Hence BIOS uses RMRR to specify these regions along with -devices that need to access these regions. OS is expected to setup -unity mappings for these regions for these devices to access these regions. - -How is IOVA generated? --- - -Well behaved drivers call pci_map_*() calls before sending command to device -that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. - -The Intel IOMMU driver allocates a virtual address per domain. Each PCIE -device has its own domain (hence protection). Devices under p2p bridges -share the virtual address with all devices under the p2p bridge due to -transaction id aliasing for p2p bridges. - -IOVA generation is pretty generic. We used the same technique as vmalloc() -but these are not global address spaces, but separate for each domain. -Different DMA engines may support different number of domains. - -We also allocate guard pages with each mapping, so we can attempt to catch -any overflow that might happen. - - -Graphics Problems? --- -If you encounter issues with graphics devices, you can try adding -option intel_iommu=igfx_off to turn off the integrated graphics engine. -If this fixes anything, please ensure you file a bug reporting the problem. - -Some exceptions to IOVA -Interrupt ranges are not address translated, (0xfee0 - 0xfeef). -The same is true for peer to peer transactions. Hence we reserve the -address from PCI MMIO ranges so they are not allocated for IOVA addresses. - - -Fault reporting -When errors are reported, the DMA engine signals via an interrupt. The fault -reason and device that caused it with fault reason is printed on console. - -See below for sample. - - -Boot Message Sample - -Something like this gets printed indicating presence of DMAR tables -in ACPI. - -ACPI: DMAR (v001 A M I OEMDMAR 0x0001 MSFT 0x0097) @ 0x7f5b5ef0 - -When DMAR is being processed and initialized by ACPI, prints DMAR locations -and any RMRR's processed:: - - ACPI DMAR:Host address width 36 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed9 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed91000 - ACPI DMAR:DRHD (flags: 0x0001)base: 0xfed93000 - ACPI DMAR:RMRR base: 0x000ed000 end: 0x000e - ACPI DMAR:RMRR base:
[PATCH v4] Documentation: x86: rework IOMMU documentation
Add preliminary documentation for AMD IOMMU and combine with the existing Intel IOMMU documentation and clean up and modernize some of the existing documentation to align with the current state of the kernel. Signed-off-by: Alex Deucher --- V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., a device) and document proper DMA API. Also correct the fact that the AMD IOMMU is not limited to managing PCI devices. v3: Fix spelling and rework text as suggested by Vasant v4: Combine Intel and AMD documents into a single document as suggested by Dave Hansen Documentation/x86/index.rst | 2 +- Documentation/x86/intel-iommu.rst | 115 -- Documentation/x86/iommu.rst | 153 ++ 3 files changed, 154 insertions(+), 116 deletions(-) delete mode 100644 Documentation/x86/intel-iommu.rst create mode 100644 Documentation/x86/iommu.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..6f8409fe0674 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -21,7 +21,7 @@ x86-specific Documentation tlb mtrr pat - intel-iommu + iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst deleted file mode 100644 index 099f13d51d5f.. --- a/Documentation/x86/intel-iommu.rst +++ /dev/null @@ -1,115 +0,0 @@ -=== -Linux IOMMU Support -=== - -The architecture spec can be obtained from the below location. - -http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf - -This guide gives a quick cheat sheet for some basic understanding. - -Some Keywords - -- DMAR - DMA remapping -- DRHD - DMA Remapping Hardware Unit Definition -- RMRR - Reserved memory Region Reporting Structure -- ZLR - Zero length reads from PCI devices -- IOVA - IO Virtual address. - -Basic stuff - -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls -them. - -What is RMRR? -- - -There are some devices the BIOS controls, for e.g USB devices to perform -PS2 emulation. The regions of memory used for these devices are marked -reserved in the e820 map. When we turn on DMA translation, DMA to those -regions will fail. Hence BIOS uses RMRR to specify these regions along with -devices that need to access these regions. OS is expected to setup -unity mappings for these regions for these devices to access these regions. - -How is IOVA generated? --- - -Well behaved drivers call pci_map_*() calls before sending command to device -that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. - -The Intel IOMMU driver allocates a virtual address per domain. Each PCIE -device has its own domain (hence protection). Devices under p2p bridges -share the virtual address with all devices under the p2p bridge due to -transaction id aliasing for p2p bridges. - -IOVA generation is pretty generic. We used the same technique as vmalloc() -but these are not global address spaces, but separate for each domain. -Different DMA engines may support different number of domains. - -We also allocate guard pages with each mapping, so we can attempt to catch -any overflow that might happen. - - -Graphics Problems? --- -If you encounter issues with graphics devices, you can try adding -option intel_iommu=igfx_off to turn off the integrated graphics engine. -If this fixes anything, please ensure you file a bug reporting the problem. - -Some exceptions to IOVA -Interrupt ranges are not address translated, (0xfee0 - 0xfeef). -The same is true for peer to peer transactions. Hence we reserve the -address from PCI MMIO ranges so they are not allocated for IOVA addresses. - - -Fault reporting -When errors are reported, the DMA engine signals via an interrupt. The fault -reason and device that caused it with fault reason is printed on console. - -See below for sample. - - -Boot Message Sample - -Something like this gets printed indicating presence of DMAR tables -in ACPI. - -ACPI: DMAR (v001 A M I OEMDMAR 0x0001 MSFT 0x0097) @ 0x7f5b5ef0 - -When DMAR is being processed and initialized by ACPI, prints DMAR locations -and any RMRR's processed:: - - ACPI DMAR:Host address width 36 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed9 - ACPI DMAR:DRHD (flags: 0x)base: 0xfed91000 - ACPI DMAR:DRHD (flags: 0x0001)base: 0xfed93000 - ACPI DMAR:RMRR base: 0x000ed000 end: 0x000e - ACPI DMAR:RMRR base: 0x7f60 end: 0x7fff - -When DMAR is
[PATCH V3 1/2] Documentation: x86: Add documentation for AMD IOMMU
Add preliminary documentation for AMD IOMMU. Signed-off-by: Alex Deucher --- V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., a device) and document proper DMA API. Also correct the fact that the AMD IOMMU is not limited to managing PCI devices. v3: Fix spelling and rework text as suggested by Vasant Documentation/x86/amd-iommu.rst | 69 +++ Documentation/x86/index.rst | 1 + Documentation/x86/intel-iommu.rst | 2 +- 3 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/amd-iommu.rst diff --git a/Documentation/x86/amd-iommu.rst b/Documentation/x86/amd-iommu.rst new file mode 100644 index ..3b1fb8fec168 --- /dev/null +++ b/Documentation/x86/amd-iommu.rst @@ -0,0 +1,69 @@ += +AMD IOMMU Support += + +The architecture spec can be obtained from the below location. + +https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf + +This guide gives a quick cheat sheet for some basic understanding. + +Some Keywords + +- IVRS - I/O Virtualization Reporting Structure +- IVDB - I/O Virtualization Definition Block +- IVHD - I/O Virtualization Hardware Definition +- IOVA - I/O Virtual Address. + +Basic stuff +--- + +ACPI enumerates and lists the different IOMMUs on the platform, and +device scope relationships between devices and which IOMMU controls +them. + +What is IVRS? +- + +The architecture defines an ACPI-compatible data structure called an I/O +Virtualization Reporting Structure (IVRS) that is used to convey information +related to I/O virtualization to system software. The IVRS describes the +configuration and capabilities of the IOMMUs contained in the platform as +well as information about the devices that each IOMMU virtualizes. + +The IVRS provides information about the following: +- IOMMUs present in the platform including their capabilities and proper configuration +- System I/O topology relevant to each IOMMU +- Peripheral devices that cannot be otherwise enumerated +- Memory regions used by SMI/SMM, platform firmware, and platform hardware. These are +generally exclusion ranges to be configured by system software. + +How is IOVA generated? +-- + +Well behaved drivers call dma_map_*() calls before sending command to device +that needs to perform DMA. Once DMA is completed and mapping is no longer +required, driver performs dma_unmap_*() calls to unmap the region. + +Fault reporting +--- + +When errors are reported, the IOMMU signals via an interrupt. The fault +reason and device that caused it is printed on the console. + +Boot Message Sample +--- + +Something like this gets printed indicating presence of the IOMMU. + + iommu: Default domain type: Translated + iommu: DMA domain TLB invalidation policy: lazy mode + +Fault reporting +^^^ + +:: + + AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xc02000 flags=0x] + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xc02000 flags=0x] + diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..15711134eb68 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -22,6 +22,7 @@ x86-specific Documentation mtrr pat intel-iommu + amd-iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 099f13d51d5f..4d3391c7bd3f 100644 --- a/Documentation/x86/intel-iommu.rst +++ b/Documentation/x86/intel-iommu.rst @@ -1,5 +1,5 @@ === -Linux IOMMU Support +Intel IOMMU Support === The architecture spec can be obtained from the below location. -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH V3 2/2] Documentation: x86: Clarify Intel IOMMU documentation
Based on feedback from Robin on the initial AMD IOMMU documentation, fix up the Intel documentation to clarify IOMMU vs device and modern DMA API. Signed-off-by: Alex Deucher --- V2: Fix spelling error in commit message Rework ACPI section as suggested by Dave Hansen Documentation/x86/intel-iommu.rst | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 4d3391c7bd3f..17d8497e506b 100644 --- a/Documentation/x86/intel-iommu.rst +++ b/Documentation/x86/intel-iommu.rst @@ -19,9 +19,8 @@ Some Keywords Basic stuff --- -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls -them. +ACPI enumerates both the IOMMUs in the platform and which IOMMU +controls a specific PCI device. What is RMRR? - @@ -36,9 +35,9 @@ unity mappings for these regions for these devices to access these regions. How is IOVA generated? -- -Well behaved drivers call pci_map_*() calls before sending command to device +Well behaved drivers call dma_map_*() calls before sending command to device that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. +required, device performs a dma_unmap_*() calls to unmap the region. The Intel IOMMU driver allocates a virtual address per domain. Each PCIE device has its own domain (hence protection). Devices under p2p bridges @@ -68,7 +67,7 @@ address from PCI MMIO ranges so they are not allocated for IOVA addresses. Fault reporting --- -When errors are reported, the DMA engine signals via an interrupt. The fault +When errors are reported, the IOMMU signals via an interrupt. The fault reason and device that caused it with fault reason is printed on console. See below for sample. -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH V3 0/2] x86 IOMMU Documentation updates
This was originally just a patch to add an AMD IOMMU documentation page, but grew into some cleanup of the Intel IOMMU documentation page. v2: AMD documentation rework Add Intel Updates v3: Further documentation reworks Alex Deucher (2): Documentation: x86: Add documentation for AMD IOMMU Documentation: x86: Clarify Intel IOMMU documentation Documentation/x86/amd-iommu.rst | 69 +++ Documentation/x86/index.rst | 1 + Documentation/x86/intel-iommu.rst | 13 +++--- 3 files changed, 76 insertions(+), 7 deletions(-) create mode 100644 Documentation/x86/amd-iommu.rst -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] Documentation: x86: Clarify Intel IOMMU documenation
Based on feedback from Robin on the initial AMD IOMMU documentation, fix up the Intel documentation to clarify IOMMU vs device and modern DMA API. Signed-off-by: Alex Deucher --- Documentation/x86/intel-iommu.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 4d3391c7bd3f..22e1934a1335 100644 --- a/Documentation/x86/intel-iommu.rst +++ b/Documentation/x86/intel-iommu.rst @@ -19,8 +19,8 @@ Some Keywords Basic stuff --- -ACPI enumerates and lists the different DMA engines in the platform, and -device scope relationships between PCI devices and which DMA engine controls +ACPI enumerates and lists the different IOMMUs in the platform, and +device scope relationships between PCI devices and which IOMMU controls them. What is RMRR? @@ -36,9 +36,9 @@ unity mappings for these regions for these devices to access these regions. How is IOVA generated? -- -Well behaved drivers call pci_map_*() calls before sending command to device +Well behaved drivers call dma_map_*() calls before sending command to device that needs to perform DMA. Once DMA is completed and mapping is no longer -required, device performs a pci_unmap_*() calls to unmap the region. +required, device performs a dma_unmap_*() calls to unmap the region. The Intel IOMMU driver allocates a virtual address per domain. Each PCIE device has its own domain (hence protection). Devices under p2p bridges @@ -68,7 +68,7 @@ address from PCI MMIO ranges so they are not allocated for IOVA addresses. Fault reporting --- -When errors are reported, the DMA engine signals via an interrupt. The fault +When errors are reported, the IOMMU signals via an interrupt. The fault reason and device that caused it with fault reason is printed on console. See below for sample. -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/2] Documentation: x86: Add documenation for AMD IOMMU
Add preliminary documenation for AMD IOMMU. Signed-off-by: Alex Deucher --- V2: incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., a device) and document proper DMA API. Also correct the fact that the AMD IOMMU is not limited to managing PCI devices. Documentation/x86/amd-iommu.rst | 69 +++ Documentation/x86/index.rst | 1 + Documentation/x86/intel-iommu.rst | 2 +- 3 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/amd-iommu.rst diff --git a/Documentation/x86/amd-iommu.rst b/Documentation/x86/amd-iommu.rst new file mode 100644 index ..6ecc4bc8c70d --- /dev/null +++ b/Documentation/x86/amd-iommu.rst @@ -0,0 +1,69 @@ += +AMD IOMMU Support += + +The architecture spec can be obtained from the below location. + +https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf + +This guide gives a quick cheat sheet for some basic understanding. + +Some Keywords + +- IVRS - I/O Virtualization Reporting Structure +- IVDB - I/O Virtualization Definition Block +- IVHD - I/O Virtualization Hardware Definition +- IOVA - I/O Virtual Address. + +Basic stuff +--- + +ACPI enumerates and lists the different IOMMUs on the platform, and +device scope relationships between devices and which IOMMU controls +them. + +What is IVRS? +- + +The architecture defines an ACPI-compatible data structure called an I/O +Virtualization Reporting Structure (IVRS) that is used to convey information +related to I/O virtualization to system software. The IVRS describes the +configuration and capabilities of the IOMMUs contained in the platform as +well as information about the devices that each IOMMU virtualizes. + +The IVRS provides information about the following: +- IOMMUs present in the platform including their capabilities and proper configuration +- System I/O topology relevant to each IOMMU +- Peripheral devices that cannot be otherwise enumerated +- Memory regions used by SMI/SMM, platform firmware, and platform hardware. These are +generally exclusion ranges to be configured by system software. + +How is IOVA generated? +-- + +Well behaved drivers call dma_map_*() calls before sending command to device +that needs to perform DMA. Once DMA is completed and mapping is no longer +required, driver performs dma_unmap_*() calls to unmap the region. + +Fault reporting +--- + +When errors are reported, the IOMMU signals via an interrupt. The fault +reason and device that caused it with fault reason is printed on console. + +Boot Message Sample +--- + +Something like this gets printed indicating presence of the IOMMU. + + iommu: Default domain type: Translated + iommu: DMA domain TLB invalidation policy: lazy mode + +Fault reporting +^^^ + +:: + + AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xc02000 flags=0x] + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xc02000 flags=0x] + diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..15711134eb68 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -22,6 +22,7 @@ x86-specific Documentation mtrr pat intel-iommu + amd-iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 099f13d51d5f..4d3391c7bd3f 100644 --- a/Documentation/x86/intel-iommu.rst +++ b/Documentation/x86/intel-iommu.rst @@ -1,5 +1,5 @@ === -Linux IOMMU Support +Intel IOMMU Support === The architecture spec can be obtained from the below location. -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] Documentation: x86: add documenation for AMD IOMMU
Add preliminary documenation for AMD IOMMU. Signed-off-by: Alex Deucher --- Documentation/x86/amd-iommu.rst | 85 +++ Documentation/x86/index.rst | 1 + Documentation/x86/intel-iommu.rst | 2 +- 3 files changed, 87 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/amd-iommu.rst diff --git a/Documentation/x86/amd-iommu.rst b/Documentation/x86/amd-iommu.rst new file mode 100644 index ..89820140fefa --- /dev/null +++ b/Documentation/x86/amd-iommu.rst @@ -0,0 +1,85 @@ += +AMD IOMMU Support += + +The architecture spec can be obtained from the below location. + +https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf + +This guide gives a quick cheat sheet for some basic understanding. + +Some Keywords + +- IVRS - I/O Virtualization Reporting Structure +- IVDB - I/O Virtualization Definition Block +- IVHD - I/O Virtualization Hardware Definition +- IOVA - I/O Virtual Address. + +Basic stuff +--- + +ACPI enumerates and lists the different DMA engines in the platform, and +device scope relationships between PCI devices and which DMA engine controls +them. + +What is IVRS? +- + +The architecture defines an ACPI-compatible data structure called an I/O +Virtualization Reporting Structure (IVRS) that is used to convey information +related to I/O virtualization to system software. The IVRS describes the +configuration and capabilities of the IOMMUs contained in the platform as +well as information about the devices that each IOMMU virtualizes. + +The IVRS provides information about the following: +- IOMMUs present in the platform including their capabilities and proper configuration +- System I/O topology relevant to each IOMMU +- Peripheral devices that cannot be otherwise enumerated +- Memory regions used by SMI/SMM, platform firmware, and platform hardware. These are +generally exclusion ranges to be configured by system software. + +How is IOVA generated? +-- + +Well behaved drivers call pci_map_*() calls before sending command to device +that needs to perform DMA. Once DMA is completed and mapping is no longer +required, device performs a pci_unmap_*() calls to unmap the region. + +The AMD IOMMU driver allocates a virtual address per domain. Each PCIE +device has its own domain (hence protection). Devices under p2p bridges +share the virtual address with all devices under the p2p bridge due to +transaction id aliasing for p2p bridges. + +IOVA generation is pretty generic. We used the same technique as vmalloc() +but these are not global address spaces, but separate for each domain. +Different DMA engines may support different number of domains. + + +Fault reporting +--- +When errors are reported, the DMA engine signals via an interrupt. The fault +reason and device that caused it with fault reason is printed on console. + +See below for sample. + + +Boot Message Sample +--- + +Something like this gets printed indicating presence of the IOMMU. + + iommu: Default domain type: Translated + iommu: DMA domain TLB invalidation policy: lazy mode + + +PCI-DMA: Using AMD IOMMU + + +Fault reporting +^^^ + +:: + + AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xc02000 flags=0x] + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xc02000 flags=0x] + diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..15711134eb68 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -22,6 +22,7 @@ x86-specific Documentation mtrr pat intel-iommu + amd-iommu intel_txt amd-memory-encryption pti diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst index 099f13d51d5f..4d3391c7bd3f 100644 --- a/Documentation/x86/intel-iommu.rst +++ b/Documentation/x86/intel-iommu.rst @@ -1,5 +1,5 @@ === -Linux IOMMU Support +Intel IOMMU Support === The architecture spec can be obtained from the below location. -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
