[PATCH] Documentation: x86: rework IOMMU documentation

2022-04-22 Thread Alex Deucher via iommu 
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

2022-04-22 Thread Alex Deucher via iommu 
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

2022-04-22 Thread Alex Deucher via iommu 
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

[PATCH V3 1/2] Documentation: x86: Add documentation for AMD IOMMU

2022-03-28 Thread Alex Deucher via 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

2022-03-28 Thread Alex Deucher via iommu 
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

2022-03-28 Thread Alex Deucher via iommu 
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

2022-03-09 Thread Alex Deucher via iommu 
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

2022-03-09 Thread Alex Deucher via 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

2022-03-08 Thread Alex Deucher via 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

Re: I got an IOMMU IO page fault. What to do now?

2021-10-27 Thread Alex Deucher 
On Wed, Oct 27, 2021 at 1:24 PM Alex Deucher  wrote:
>
> On Wed, Oct 27, 2021 at 1:20 PM Robin Murphy  wrote:
> >
> > On 27/10/2021 5:45 pm, Paul Menzel wrote:
> > > Dear Robin,
> > >
> > >
> > > On 25.10.21 18:01, Robin Murphy wrote:
> > >> On 2021-10-25 12:23, Christian König wrote:
> > >
> > >>> not sure how the IOMMU gives out addresses, but the printed ones look
> > >>> suspicious to me. Something like we are using an invalid address like
> > >>> -1 or similar.
> > >>
> > >> FWIW those look like believable DMA addresses to me, assuming that the
> > >> DMA mapping APIs are being backed iommu_dma_ops and the device has a
> > >> 40-bit DMA mask, since the IOVA allocator works top-down.
> > >>
> > >> Likely causes are either a race where the dma_unmap_*() call happens
> > >> before the hardware has really stopped accessing the relevant
> > >> addresses, or the device's DMA mask has been set larger than it should
> > >> be, and thus the upper bits have been truncated in the round-trip
> > >> through the hardware.
> > >>
> > >> Given the addresses involved, my suspicions would initially lean
> > >> towards the latter case - the faults are in the very topmost pages
> > >> which imply they're the first things mapped in that range. The other
> > >> contributing factor being the trick that the IOVA allocator plays for
> > >> PCI devices, where it tries to prefer 32-bit addresses. Thus you're
> > >> only likely to see this happen once you already have ~3.5-4GB of live
> > >> DMA-mapped memory to exhaust the 32-bit IOVA space (minus some
> > >> reserved areas) and start allocating from the full DMA mask. You
> > >> should be able to check that with a 5.13 or newer kernel by booting
> > >> with "iommu.forcedac=1" and seeing if it breaks immediately
> > >> (unfortunately with an older kernel you'd have to manually hack
> > >> iommu_dma_alloc_iova() to the same effect).
> > >
> > > I booted Linux 5.15-rc7 with `iommu.forcedac=1` and the system booted,
> > > and I could log in remotely over SSH. Please find the Linux kernel
> > > messages attached. (The system logs say lightdm failed to start, but it
> > > might be some other issue due to a change in the operating system.)
> >
> > OK, that looks like it's made the GPU blow up straight away, which is
> > what I was hoping for (and also appears to reveal another bug where it's
> > not handling probe failure very well - possibly trying to remove a
> > non-existent audio device?). Lightdm presumably fails to start because
> > it doesn't find any display devices, since amdgpu failed to probe.
> >
> > If you can boot the same kernel without "iommu.forcedac" and get a
> > successful probe and working display, that will imply that it is
> > managing to work OK with 32-bit DMA addresses, at which point I'd have
> > to leave it to Christian and Alex to figure out exactly where DMA
> > addresses are getting mangled. The only thing that stands out to me is
> > the reference to "gfx_v6_0", which makes me wonder whether it's related
> > to gmc_v6_0_sw_init() where a 44-bit DMA mask gets set. If so, that
> > would suggest that either this particular model of GPU is more limited
> > than expected, or that SoC only has 40 bits of address wired up between
> > the PCI host bridge and the IOMMU.
>
> That device only has a 40 bit DMA mask.  It looks like the code is wrong 
> there.

The attached patch should fix it.

Alex
From 39735f761234fa480d393b1477dd9d4006783f34 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Wed, 27 Oct 2021 13:26:19 -0400
Subject: [PATCH] drm/amdgpu/gmc6: fix DMA mask

The DMA mask on SI parts is 40 bits not 44.  Looks like a copy
paste typo.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 0e81e03e9b49..a9354cb2d639 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -841,7 +841,7 @@ static int gmc_v6_0_sw_init(void *handle)
 
 	adev->gmc.mc_mask = 0xffULL;
 
-	r = dma_set_mask_and_coherent(adev->dev, DMA_BIT_MASK(44));
+	r = dma_set_mask_and_coherent(adev->dev, DMA_BIT_MASK(40));
 	if (r) {
 		dev_warn(adev->dev, "No suitable DMA available.\n");
 		return r;
-- 
2.31.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: I got an IOMMU IO page fault. What to do now?

2021-10-27 Thread Alex Deucher 
On Wed, Oct 27, 2021 at 1:20 PM Robin Murphy  wrote:
>
> On 27/10/2021 5:45 pm, Paul Menzel wrote:
> > Dear Robin,
> >
> >
> > On 25.10.21 18:01, Robin Murphy wrote:
> >> On 2021-10-25 12:23, Christian König wrote:
> >
> >>> not sure how the IOMMU gives out addresses, but the printed ones look
> >>> suspicious to me. Something like we are using an invalid address like
> >>> -1 or similar.
> >>
> >> FWIW those look like believable DMA addresses to me, assuming that the
> >> DMA mapping APIs are being backed iommu_dma_ops and the device has a
> >> 40-bit DMA mask, since the IOVA allocator works top-down.
> >>
> >> Likely causes are either a race where the dma_unmap_*() call happens
> >> before the hardware has really stopped accessing the relevant
> >> addresses, or the device's DMA mask has been set larger than it should
> >> be, and thus the upper bits have been truncated in the round-trip
> >> through the hardware.
> >>
> >> Given the addresses involved, my suspicions would initially lean
> >> towards the latter case - the faults are in the very topmost pages
> >> which imply they're the first things mapped in that range. The other
> >> contributing factor being the trick that the IOVA allocator plays for
> >> PCI devices, where it tries to prefer 32-bit addresses. Thus you're
> >> only likely to see this happen once you already have ~3.5-4GB of live
> >> DMA-mapped memory to exhaust the 32-bit IOVA space (minus some
> >> reserved areas) and start allocating from the full DMA mask. You
> >> should be able to check that with a 5.13 or newer kernel by booting
> >> with "iommu.forcedac=1" and seeing if it breaks immediately
> >> (unfortunately with an older kernel you'd have to manually hack
> >> iommu_dma_alloc_iova() to the same effect).
> >
> > I booted Linux 5.15-rc7 with `iommu.forcedac=1` and the system booted,
> > and I could log in remotely over SSH. Please find the Linux kernel
> > messages attached. (The system logs say lightdm failed to start, but it
> > might be some other issue due to a change in the operating system.)
>
> OK, that looks like it's made the GPU blow up straight away, which is
> what I was hoping for (and also appears to reveal another bug where it's
> not handling probe failure very well - possibly trying to remove a
> non-existent audio device?). Lightdm presumably fails to start because
> it doesn't find any display devices, since amdgpu failed to probe.
>
> If you can boot the same kernel without "iommu.forcedac" and get a
> successful probe and working display, that will imply that it is
> managing to work OK with 32-bit DMA addresses, at which point I'd have
> to leave it to Christian and Alex to figure out exactly where DMA
> addresses are getting mangled. The only thing that stands out to me is
> the reference to "gfx_v6_0", which makes me wonder whether it's related
> to gmc_v6_0_sw_init() where a 44-bit DMA mask gets set. If so, that
> would suggest that either this particular model of GPU is more limited
> than expected, or that SoC only has 40 bits of address wired up between
> the PCI host bridge and the IOMMU.

That device only has a 40 bit DMA mask.  It looks like the code is wrong there.

Alex


>
> Cheers,
> Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

2021-03-09 Thread Alex Deucher 
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
 wrote:
>
> Hi Felix,
>
> On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > > I think the proper fix would be to not rely on custom hooks into a 
> > > particular
> > > IOMMU driver, but to instead ensure that the amdgpu driver can do 
> > > everything
> > > it needs through the regular linux/iommu.h interfaces. I realize this
> > > is more work,
> > > but I wonder if you've tried that, and why it didn't work out.
> >
> > As far as I know this hasn't been tried. I see that intel-iommu has its
> > own SVM thing, which seems to be similar to what our IOMMUv2 does. I
> > guess we'd have to abstract that into a common API.
>
> The common API was added in 26b25a2b98e4 and implemented by the Intel
> driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU
> ops:
> .dev_has_feat()
> .dev_feat_enabled()
> .dev_enable_feat()
> .dev_disable_feat()
> .sva_bind()
> .sva_unbind()
> .sva_get_pasid()
>
> And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA)
> followed by iommu_sva_bind_device().
>
> If I remember correctly the biggest obstacle for KFD is the PASID
> allocation, done by the GPU driver instead of the IOMMU driver, but there
> may be others.

IIRC, we tried to make the original IOMMUv2 functionality generic but
other vendors were not interested at the time, so it ended up being
AMD specific and since nothing else was using the pasid allocations we
put them in the GPU driver.  I guess if this is generic now, it could
be moved to a common API and taken out of the driver.

Alex
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [Linaro-mm-sig] [PATCH v5 05/38] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()

2020-09-25 Thread Alex Deucher 
On Tue, Sep 22, 2020 at 2:28 AM Marek Szyprowski
 wrote:
>
> Hi Alex,
>
> On 22.09.2020 01:15, Alex Goins wrote:
> > Tested-by: Alex Goins 
> >
> > This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> > AMDGPU in v5.9.
>
> Thanks for testing!
>
> > Commit 39913934 similarly revamped AMDGPU to use sgtable helper functions. 
> > When
> > it changed from dma_map_sg_attrs() to dma_map_sgtable(), as a side effect it
> > started correctly updating sgt->nents to the return value of 
> > dma_map_sg_attrs().
> > However, drm_prime_sg_to_page_addr_arrays() incorrectly uses sgt->nents to
> > iterate over pages, rather than sgt->orig_nents, resulting in it now 
> > returning
> > the incorrect number of pages on AMDGPU.
> >
> > I had written a patch that changes drm_prime_sg_to_page_addr_arrays() to use
> > for_each_sgtable_sg() instead of for_each_sg(), iterating using 
> > sgt->orig_nents:
> >
> > -   for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> > +   for_each_sgtable_sg(sgt, sg, count) {
> >
> > This patch takes it further, but still has the effect of fixing the number 
> > of
> > pages that drm_prime_sg_to_page_addr_arrays() returns. Something like this
> > should be included in v5.9 to prevent a regression with AMDGPU.
>
> Probably the easiest way to handle a fix for v5.9 would be to simply
> merge the latest version of this patch also to v5.9-rcX:
> https://lore.kernel.org/dri-devel/20200904131711.12950-3-m.szyprow...@samsung.com/
>
>
> This way we would get it fixed and avoid possible conflict in the -next.
> Do you have any AMDGPU fixes for v5.9 in the queue? Maybe you can add
> that patch to the queue? Dave: would it be okay that way?

I think this should go into drm-misc for 5.9 since it's an update to
drm_prime.c.  Is that patch ready to merge?
Acked-by: Alex Deucher 

Alex

>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

2020-08-26 Thread Alex Deucher 
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy  wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
>  } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> +   if (sgl && sg_dma_len(sgl) == 0)
> +   s.sgp = NULL;
>
> if (s.sgp) {
> .
> """
> at location [1].
> but it doens't fix the problem.
>
> You're right though, this change does need to be made, this code
> doesn't handle pages of sg_dma_len(sg) == 0 correctly
> So my guess is that we have more bugs in other parts of the i915
> driver (or there is a problem with my "sg_dma_len == 0" fix above).
> I have been trying to spot where else the code might be buggy but I
> haven't had any luck so far.
>
> I'm doing a microconfernce (at LPC 2020) this wednesdays [1] on this
> if you're interested in attending.
> I'm hoping I can chat about it with a few people and find how can
> reproduce and fix this issues. I don't have any more time I can give
> to this unfortunately and it would be a shame for the work to go to
> waste.
>
> [0] 
> https://github.com/torvalds/linux/blob/d012a7190fc1fd72ed48911e77ca97ba4521bccd/drivers/gpu/drm/i915/i915_scatterlist.h#L28
> [1] https://linuxplumbersconf.org/event/7/contributions/846/
>
> On Fri, 29 May 2020 at 22:21, Logan Gunthorpe  wrote:
> >
> >
> >
> > On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> > > Patches are pending:
> > > https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/
> >
> > Cool, nice! Though, I still don't think that fixes the issue in
> > i915_scatterlist.h given it still ignores sg_dma_len() and strictly
> > relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
> > is the bug that got in Tom's way.
> >
> > >> However, as Robin pointed out, there are other ugly tricks like stopping
> > >> iterating through the SGL when sg_dma_len() is zero. For example, the
> > >> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> > >> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> > >> have complained by now seeing AMD has already switched to IOMMU-DMA.

We ran into the same issue with amdgpu and radeon when the AMD IOMMU
driver was converted and had to fix it as well.  The relevant fixes
were:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42e67b479eab6d26459b80b4867298232b0435e7
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0199172f933342d8b1011aae2054a695c25726f4
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47f7826c520ecd92ffbffe59ecaa2fe61e42ec70
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0f83d164fb8f3a2b7bc379a6c1e27d1123a9eab

Alex

> > >
> > > I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> > > somewhere documented.
> >
> > Well whatever you want to call it, it is ugly to have some drivers doing
> > one thing with the returned value and others assuming there's an extra
> > zero at the end. It just causes confusion for people reading/copying the
> > code. It would be better if they are all consistent. However, I concede
> > stopping at zero should not be broken, presently.
> >
> > Logan
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

2020-04-09 Thread Alex Deucher 
On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter  wrote:
>
> On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
>  wrote:
> >
> > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > isn't going to help anyone else.  Remove the hack as it is the last
> > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > >
> > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > layer in drm from back then isn't going to work in other places. I guess
> > > should have at least an ack from him, in case anyone still cares about
> > > this on ppc. Adding Ben to cc.
> >
> > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> >
> > There were machines using that (440 based iirc), though I honestly
> > can't tell if anybody still uses any of it.
>
> agp subsystem still seems to happily do that (vmalloc memory for
> device access), never having been ported to dma apis (or well
> converted to iommu drivers, which they kinda are really). So I think
> this all still works exactly as back then, even with the kms radeon
> drivers. Question really is whether we have users left, and I have no
> clue about that either.
>
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp.

All radeons have a built in remapping table to handle non-AGP systems.
On the earlier radeons it wasn't quite as performant as AGP, but it
was always more reliable because AGP is AGP.  Maybe it's time to let
AGP go?

Alex

> -Daniel
>
> > Cheers,
> > Ben.
> >
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Christoph Hellwig 
> > > > ---
> > > >  drivers/gpu/drm/drm_scatter.c | 11 +--
> > > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_scatter.c 
> > > > b/drivers/gpu/drm/drm_scatter.c
> > > > index ca520028b2cb..f4e6184d1877 100644
> > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > @@ -43,15 +43,6 @@
> > > >
> > > >  #define DEBUG_SCATTER 0
> > > >
> > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > -{
> > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > -   return __vmalloc(size, GFP_KERNEL, 
> > > > pgprot_noncached_wc(PAGE_KERNEL));
> > > > -#else
> > > > -   return vmalloc_32(size);
> > > > -#endif
> > > > -}
> > > > -
> > > >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > >  {
> > > > struct page *page;
> > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, 
> > > > void *data,
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > if (!entry->virtual) {
> > > > kfree(entry->busaddr);
> > > > kfree(entry->pagelist);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability

2019-01-29 Thread Alex Deucher 
On Tue, Jan 29, 2019 at 3:25 PM Logan Gunthorpe  wrote:
>
>
>
> On 2019-01-29 12:56 p.m., Alex Deucher wrote:
> > On Tue, Jan 29, 2019 at 12:47 PM  wrote:
> >>
> >> From: Jérôme Glisse 
> >>
> >> device_test_p2p() return true if two devices can peer to peer to
> >> each other. We add a generic function as different inter-connect
> >> can support peer to peer and we want to genericaly test this no
> >> matter what the inter-connect might be. However this version only
> >> support PCIE for now.
> >>
> >
> > What about something like these patches:
> > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p=4fab9ff69cb968183f717551441b475fabce6c1c
> > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p=f90b12d41c277335d08c9dab62433f27c0fadbe5
> > They are a bit more thorough.
>
> Those new functions seem to have a lot of overlap with the code that is
> already upstream in p2pdma Perhaps you should be improving the
> p2pdma functions if they aren't suitable for what you want already
> instead of creating new ones.

Could be.  Those patches are pretty old.  They probably need to be
rebased on the latest upstream p2p stuff.

Alex
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability

2019-01-29 Thread Alex Deucher 
On Tue, Jan 29, 2019 at 12:47 PM  wrote:
>
> From: Jérôme Glisse 
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> matter what the inter-connect might be. However this version only
> support PCIE for now.
>

What about something like these patches:
https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p=4fab9ff69cb968183f717551441b475fabce6c1c
https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p=f90b12d41c277335d08c9dab62433f27c0fadbe5
They are a bit more thorough.

Alex

> Signed-off-by: Jérôme Glisse 
> Cc: Logan Gunthorpe 
> Cc: Greg Kroah-Hartman 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: Christian Koenig 
> Cc: Felix Kuehling 
> Cc: Jason Gunthorpe 
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Christoph Hellwig 
> Cc: Marek Szyprowski 
> Cc: Robin Murphy 
> Cc: Joerg Roedel 
> Cc: iommu@lists.linux-foundation.org
> ---
>  drivers/pci/p2pdma.c   | 27 +++
>  include/linux/pci-p2pdma.h |  6 ++
>  2 files changed, 33 insertions(+)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index c52298d76e64..620ac60babb5 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -797,3 +797,30 @@ ssize_t pci_p2pdma_enable_show(char *page, struct 
> pci_dev *p2p_dev,
> return sprintf(page, "%s\n", pci_name(p2p_dev));
>  }
>  EXPORT_SYMBOL_GPL(pci_p2pdma_enable_show);
> +
> +bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> +   struct pci_dev *pciA, *pciB;
> +   bool ret;
> +   int tmp;
> +
> +   /*
> +* For now we only support PCIE peer to peer but other inter-connect
> +* can be added.
> +*/
> +   pciA = find_parent_pci_dev(devA);
> +   pciB = find_parent_pci_dev(devB);
> +   if (pciA == NULL || pciB == NULL) {
> +   ret = false;
> +   goto out;
> +   }
> +
> +   tmp = upstream_bridge_distance(pciA, pciB, NULL);
> +   ret = tmp < 0 ? false : true;
> +
> +out:
> +   pci_dev_put(pciB);
> +   pci_dev_put(pciA);
> +   return false;
> +}
> +EXPORT_SYMBOL_GPL(pci_test_p2p);
> diff --git a/include/linux/pci-p2pdma.h b/include/linux/pci-p2pdma.h
> index bca9bc3e5be7..7671cc499a08 100644
> --- a/include/linux/pci-p2pdma.h
> +++ b/include/linux/pci-p2pdma.h
> @@ -36,6 +36,7 @@ int pci_p2pdma_enable_store(const char *page, struct 
> pci_dev **p2p_dev,
> bool *use_p2pdma);
>  ssize_t pci_p2pdma_enable_show(char *page, struct pci_dev *p2p_dev,
>bool use_p2pdma);
> +bool pci_test_p2p(struct device *devA, struct device *devB);
>  #else /* CONFIG_PCI_P2PDMA */
>  static inline int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar,
> size_t size, u64 offset)
> @@ -97,6 +98,11 @@ static inline ssize_t pci_p2pdma_enable_show(char *page,
>  {
> return sprintf(page, "none\n");
>  }
> +
> +static inline bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> +   return false;
> +}
>  #endif /* CONFIG_PCI_P2PDMA */
>
>
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] fix double ;;s in code

2018-02-20 Thread Alex Deucher 
On Tue, Feb 20, 2018 at 3:03 AM, Jani Nikula
 wrote:
> On Mon, 19 Feb 2018, Pavel Machek  wrote:
>> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>>> Yeah, pls split this into one patch per area, with a suitable patch
>>> subject prefix. Look at git log of each file to get a feeling for what's
>>> the standard in each area.
>>
>> Yeah I can spend hour spliting it, and then people will ignore it
>> anyway.
>>
>> If you care about one of the files being modified, please fix the
>> bug, ";;" is a clear bug.
>>
>> If you don't care ... well I don't care either.
>
> Look, if this causes just one conflict down the line because it touches
> the kernel all over the place, then IMO it already wasn't worth
> it. Merge conflicts are inevitable, but there's no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
>
> Had it been split up, the drm parts would've been merged already.

FWIW, the amdgpu and scheduler changes have already been fixed for -next.

Alex

>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

2017-03-17 Thread Alex Deucher 
On Fri, Mar 17, 2017 at 8:15 AM, Daniel Drake  wrote:
> Hi,
>
> On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander
>  wrote:
>> > We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor
>> > Acer Aspire E5-523 with standard configurations because during boot
>> > the screen is flooded with the following error message over and over:
>> >
>> >   AMD-Vi: Completion-Wait loop timed out
>>
>> We ran into similar issues and bisected it to commit 
>> b1516a14657acf81a587e9a6e733a881625eee53.  I'm not too familiar with the 
>> IOMMU hardware to know if this is an iommu or display driver issue yet.
>
> We can confirm that reverting this commit solves the issue.
>
> Given that that commit is an optimization, but it has introduced a
> regression on multiple platforms, and has been like this for 8 months,
> it would be common practice to now revert this patch upstream until
> the regression is fixed. Could you please send a new patch to do this?
>
> Also, we would be happy to test any real solutions to this issue while
> we still have the affected units in hand.

No objections to a revert here.

Alex


>
> Thanks
> Daniel
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [Bugfix]

2015-07-30 Thread Alex Deucher 
On Thu, Jul 30, 2015 at 12:44 PM, Jiang Liu jiang@linux.intel.com wrote:
 Hi Alexander, Mark, Alex,
 Could you please help to apply the debug patch and send me back
 the dmesg? Please also help to turn kernel paramemter apic=debug.

See attached.

Thanks,

Alex


 Hi Mark,
 It seems that this regression is caused by support of multiple-MSI,
 but I have no PCI card supportting multiple-MSI at hand. So may I remotely
 access your system from Intel internal network?  That will definitely speed
 up fix.
 Thanks!
 Gerry

 Signed-off-by: Jiang Liu jiang@linux.intel.com
 ---
  drivers/iommu/amd_iommu.c   |   15 +--
  drivers/iommu/intel_irq_remapping.c |4 
  2 files changed, 17 insertions(+), 2 deletions(-)

 diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
 index a57e9b749895..c039ed9333a4 100644
 --- a/drivers/iommu/amd_iommu.c
 +++ b/drivers/iommu/amd_iommu.c
 @@ -3916,8 +3916,8 @@ static void irq_remapping_prepare_irte(struct 
 amd_ir_data *data,
 union irte *irte = data-irte_entry;
 struct IO_APIC_route_entry *entry;

 -   data-irq_2_irte.devid = devid;
 -   data-irq_2_irte.index = index + sub_handle;
 +   irte_info-devid = devid;
 +   irte_info-index = index + sub_handle;

 /* Setup IRTE for IOMMU */
 irte-val = 0;
 @@ -3926,6 +3926,10 @@ static void irq_remapping_prepare_irte(struct 
 amd_ir_data *data,
 irte-fields.destination = irq_cfg-dest_apicid;
 irte-fields.dm  = apic-irq_dest_mode;
 irte-fields.valid   = 1;
 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: IRTE%d vector %d APICID%d data%p cfg%p\n,
 +   irte_info-index, irte-fields.vector,
 +   irte-fields.destination, data, irq_cfg);

 switch (info-type) {
 case X86_IRQ_ALLOC_TYPE_IOAPIC:
 @@ -3972,6 +3976,9 @@ static int irq_remapping_alloc(struct irq_domain 
 *domain, unsigned int virq,
 info-type != X86_IRQ_ALLOC_TYPE_MSIX)
 return -EINVAL;

 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: allocate %d MSI IRQ, VIRQ%d\n, nr_irqs, 
 virq);
 +
 /*
  * With IRQ remapping enabled, don't need contiguous CPU vectors
  * to support multiple MSI interrupts.
 @@ -3986,6 +3993,8 @@ static int irq_remapping_alloc(struct irq_domain 
 *domain, unsigned int virq,
 ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
 if (ret  0)
 return ret;
 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: allocate parent returns %d\n, ret);

 ret = -ENOMEM;
 data = kzalloc(sizeof(*data), GFP_KERNEL);
 @@ -4005,6 +4014,8 @@ static int irq_remapping_alloc(struct irq_domain 
 *domain, unsigned int virq,
 kfree(data);
 goto out_free_parent;
 }
 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: allocate IRTE index %d\n, index);

 for (i = 0; i  nr_irqs; i++) {
 irq_data = irq_domain_get_irq_data(domain, virq + i);
 diff --git a/drivers/iommu/intel_irq_remapping.c 
 b/drivers/iommu/intel_irq_remapping.c
 index f15692a410c7..bb093bc6b334 100644
 --- a/drivers/iommu/intel_irq_remapping.c
 +++ b/drivers/iommu/intel_irq_remapping.c
 @@ -1234,6 +1234,8 @@ static void intel_irq_remapping_prepare_irte(struct 
 intel_ir_data *data,
   MSI_ADDR_IR_SHV |
   MSI_ADDR_IR_INDEX1(index) |
   MSI_ADDR_IR_INDEX2(index);
 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: allocate index%d, subhandle%d, 
 irte%llx,%llx\n, index, sub_handle, irte-high, irte-low);
 break;

 default:
 @@ -1305,6 +1307,8 @@ static int intel_irq_remapping_alloc(struct irq_domain 
 *domain,
 kfree(data);
 goto out_free_parent;
 }
 +   if (info-type == X86_IRQ_ALLOC_TYPE_MSI)
 +   pr_warn(irqdomain: allocate VIRQ%d, count%d, index%d\n, 
 virq, nr_irqs, index);

 for (i = 0; i  nr_irqs; i++) {
 irq_data = irq_domain_get_irq_data(domain, virq + i);
 --
 1.7.10.4



dmesg.apic-debug
Description: Binary data
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-12 Thread Alex Deucher 
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 * Sascha Hauer wrote:
 You might want to have a look at the sdrm patches I recently posted to
 dri-devel and arm Linux Kernel. Among other things they allow to
 register crtcs/connectors/encoders seperately so that each of them can
 have its own representation in the devicetree. I haven't looked into
 devicetree support for DRM, but with or without devicetree the problem
 that we do not have a single PCI card for registering all DRM components
 is the same.

 I'll do that. One interesting use-case that's been on my mind for some time
 is if it would be possible to provide a CRTC via DRM that isn't part of the
 SoC or DRM device but which can display a framebuffer prepared by the DRM
 framework.

 In other words I would like to use the Tegra hardware to render content into
 a framebuffer (using potentially the 3D engine or HW accelerated video
 decoding blocks) but display that framebuffer with a CRTC registered by a
 different driver (perhaps provided by a PCIe or USB device).

 I think such a setup would be possible if the CRTC registration can be
 decoupled from the DRM driver. Perhaps sdrm even supports that already?

You should be able to do something like that already with dma_buf and
the drm prime infrastructure.  There's even a drm driver for the udl
USB framebuffer devices.

Alex
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu