[PATCH 0/2] iommu/amd: Fix default domain selection for PASID-capable devices

[PATCH 0/2] iommu/amd: Fix default domain selection for PASID-capable devices

[Vasant Hegde]

This series addresses a long-standing issue in the default domain
selection path of the AMD IOMMU driver.

Currently, the driver unconditionally forces an identity domain on all
devices that support PASID (Process Address Space ID).

This series introduces a more targeted approach: instead of applying identity
domain assignment globally to all PASID-capable devices, quirks are added only
for specific GPUs. All remaining PASID-capable devices are now allowed to boot
with a paging domain, enabling proper use of page tables (v2 page table).

In addition, this series adds an ATS (Address Translation Service) quirk
for the "Radeon GPU WX 4100" to ensure correct operation when booted
with a paging domain.

Vasant Hegde (2):
  PCI: Mark Radeon Pro WX 4100 ATS as broken
  iommu/amd: Force identity mode for selected GPUs only

 drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
 drivers/pci/quirks.c      |  2 ++
 2 files changed, 47 insertions(+), 11 deletions(-)

-- 
2.31.1

[PATCH 1/2] PCI: Mark Radeon Pro WX 4100 ATS as broken

[Vasant Hegde]

If ATS is enabled then IOMMU logs below error and GPU fails to
initialize.

[  103.687137] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=0000:c4:00.0 address=0x1080006060]

Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
---
 drivers/pci/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f7846f..d55657347d88 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5686,6 +5686,8 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7340, quirk_amd_harvest_no_ats);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7341, quirk_amd_harvest_no_ats);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7347, quirk_amd_harvest_no_ats);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x734f, quirk_amd_harvest_no_ats);
+/* Radeon Pro WX 4100 */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x67e3, quirk_amd_harvest_no_ats);
 /* AMD Raven platform iGPU */
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x15d8, quirk_amd_harvest_no_ats);
 
-- 
2.31.1

Re: [PATCH 1/2] PCI: Mark Radeon Pro WX 4100 ATS as broken

[Bjorn Helgaas]

On Thu, Jul 23, 2026 at 06:15:47AM +0000, Vasant Hegde wrote:
> If ATS is enabled then IOMMU logs below error and GPU fails to
> initialize.
> 
> [  103.687137] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=0000:c4:00.0 address=0x1080006060]

Is this a published erratum?

Is there enough benefit to using ATS to make it worthwhile?  It would have
to be a pretty substantial benefit to outweigh the end-user frustration of 
defects like this.

If ATS isn't going to be validated by vendors, maybe we should disable it
on all AMD/ATI devices?  Or maybe only the GPUs?

> Suggested-by: Alex Deucher <alexander.deucher@amd.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b09f27f7846f..d55657347d88 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5686,6 +5686,8 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7340, quirk_amd_harvest_no_ats);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7341, quirk_amd_harvest_no_ats);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7347, quirk_amd_harvest_no_ats);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x734f, quirk_amd_harvest_no_ats);
> +/* Radeon Pro WX 4100 */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x67e3, quirk_amd_harvest_no_ats);
>  /* AMD Raven platform iGPU */
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x15d8, quirk_amd_harvest_no_ats);
>  
> -- 
> 2.31.1
> 

Re: [PATCH 1/2] PCI: Mark Radeon Pro WX 4100 ATS as broken

[Mario Limonciello]

On 7/23/26 10:42, Bjorn Helgaas wrote:
> On Thu, Jul 23, 2026 at 06:15:47AM +0000, Vasant Hegde wrote:
>> If ATS is enabled then IOMMU logs below error and GPU fails to
>> initialize.
>>
>> [  103.687137] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=0000:c4:00.0 address=0x1080006060]
> 
> Is this a published erratum?
> 
> Is there enough benefit to using ATS to make it worthwhile?  It would have
> to be a pretty substantial benefit to outweigh the end-user frustration of
> defects like this.
> 
> If ATS isn't going to be validated by vendors, maybe we should disable it
> on all AMD/ATI devices?  Or maybe only the GPUs?

Isn't that a pretty big performance impact to have ATS disabled?

At least I don't think I would want a blanket policy without data 
supporting it's a good idea.

> 
>> Suggested-by: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: linux-pci@vger.kernel.org
>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>> ---
>>   drivers/pci/quirks.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index b09f27f7846f..d55657347d88 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -5686,6 +5686,8 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7340, quirk_amd_harvest_no_ats);
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7341, quirk_amd_harvest_no_ats);
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7347, quirk_amd_harvest_no_ats);
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x734f, quirk_amd_harvest_no_ats);
>> +/* Radeon Pro WX 4100 */
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x67e3, quirk_amd_harvest_no_ats);
>>   /* AMD Raven platform iGPU */
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x15d8, quirk_amd_harvest_no_ats);
>>   
>> -- 
>> 2.31.1
>>

Re: [PATCH 1/2] PCI: Mark Radeon Pro WX 4100 ATS as broken

[Vasant Hegde]

On 7/23/2026 9:15 PM, Mario Limonciello wrote:
> 
> 
> On 7/23/26 10:42, Bjorn Helgaas wrote:
>> On Thu, Jul 23, 2026 at 06:15:47AM +0000, Vasant Hegde wrote:
>>> If ATS is enabled then IOMMU logs below error and GPU fails to
>>> initialize.
>>>
>>> [  103.687137] iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
>>> device=0000:c4:00.0 address=0x1080006060]
>>
>> Is this a published erratum?
>>
>> Is there enough benefit to using ATS to make it worthwhile?  It would have
>> to be a pretty substantial benefit to outweigh the end-user frustration of
>> defects like this.
>>
>> If ATS isn't going to be validated by vendors, maybe we should disable it
>> on all AMD/ATI devices?  Or maybe only the GPUs?
> 
> Isn't that a pretty big performance impact to have ATS disabled?
> 
> At least I don't think I would want a blanket policy without data supporting
> it's a good idea.

Ack. I will find this GPU internally and will run some more experiement and get
back to you.


-Vasant

[PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Certain AMD GPU's must always be in identity mode. Currently its enforced
using PASID check. It worked fine as most GPU's has PASID feature. But
this means, identity mode enforcement is done for all PASID capable devices.

Previously it made sense as domain allocation API
(iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
check device capability and decide best suited page table type (v1 or
v2). With recent enhancement to driver code, it uses
domain_alloc_paging_flags() ops for all paging mode domain allocation.
This can check device/flags and allocate best suited page table (v1 or v2).
Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
GPUs only.

With this change system booted with DMA translation mode will select:
 * Guest (v2) page table for PASID capable device
 * Host (v1) page table for non-PASID capable device

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
---
 drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
 1 file changed, 45 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 563f9c2672d5..fe642e33c87d 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
 	return dev_data->defer_attach;
 }
 
+static bool quirks_force_identity_mapping(struct pci_dev *pdev)
+{
+	struct pci_dev *root_port;
+	int class = pdev->class >> 8;
+
+	/* AMD GPU vendor ID */
+	if (pdev->vendor != PCI_VENDOR_ID_ATI)
+		return false;
+
+	/* GPU class */
+	if (class != PCI_CLASS_DISPLAY_VGA &&
+	    class != PCI_CLASS_DISPLAY_OTHER)
+		return false;
+
+	root_port = pcie_find_root_port(pdev);
+	if (!root_port)
+		return false;
+
+	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */
+	if (root_port->vendor != PCI_VENDOR_ID_ATI)
+		return true;
+
+	/* Rest all are dGPUs and works fine with DMA mode */
+	return false;
+}
+
 static int amd_iommu_def_domain_type(struct device *dev)
 {
 	struct iommu_dev_data *dev_data;
@@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
 	if (!dev_data)
 		return 0;
 
+	if (!dev_is_pci(dev))
+		return 0;
+
 	/* Always use DMA domain for untrusted device */
-	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
+	if (to_pci_dev(dev)->untrusted)
 		return IOMMU_DOMAIN_DMA;
 
-	/*
-	 * Do not identity map IOMMUv2 capable devices when:
-	 *  - memory encryption is active, because some of those devices
-	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
-	 *    and require remapping.
-	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
-	 */
-	if (pdev_pasid_supported(dev_data) &&
-	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
-	    !amd_iommu_snp_en) {
+	/* Apply device specific quirks */
+	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
+
+		/*
+		 * When memory encryption is active, some of these devices
+		 * don't have the encryption bit in their DMA-mask and
+		 * require remapping.
+		 */
+		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
+			return 0;
+
+		/* DTE[Mode]=0 is prohibited when SNP is enabled */
+		if (amd_iommu_snp_en)
+			return 0;
+
 		return IOMMU_DOMAIN_IDENTITY;
 	}
 
-- 
2.31.1

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Ankit Soni]

On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
> Certain AMD GPU's must always be in identity mode. Currently its enforced
> using PASID check. It worked fine as most GPU's has PASID feature. But
> this means, identity mode enforcement is done for all PASID capable devices.
> 
> Previously it made sense as domain allocation API
> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
> check device capability and decide best suited page table type (v1 or
> v2). With recent enhancement to driver code, it uses
> domain_alloc_paging_flags() ops for all paging mode domain allocation.
> This can check device/flags and allocate best suited page table (v1 or v2).
> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
> GPUs only.
> 
> With this change system booted with DMA translation mode will select:
>  * Guest (v2) page table for PASID capable device
>  * Host (v1) page table for non-PASID capable device
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
> ---
>  drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>  1 file changed, 45 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 563f9c2672d5..fe642e33c87d 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
>  	return dev_data->defer_attach;
>  }
>  
> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
> +{
> +	struct pci_dev *root_port;
> +	int class = pdev->class >> 8;
> +
> +	/* AMD GPU vendor ID */
> +	if (pdev->vendor != PCI_VENDOR_ID_ATI)
> +		return false;
> +
> +	/* GPU class */
> +	if (class != PCI_CLASS_DISPLAY_VGA &&
> +	    class != PCI_CLASS_DISPLAY_OTHER)
> +		return false;
> +
> +	root_port = pcie_find_root_port(pdev);
> +	if (!root_port)
> +		return false;
> +
> +	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */
> +	if (root_port->vendor != PCI_VENDOR_ID_ATI)
> +		return true;

Hi Vasant,

For a discrete GPU, pcie_find_root_port() may walk up to the system root port. 
On an AMD platform that root port is vendored PCI_VENDOR_ID_AMD, which is not ATI. 
so this device will be forced to identity.
Is that a valid scenario?

-Ankit

> +
> +	/* Rest all are dGPUs and works fine with DMA mode */
> +	return false;
> +}
> +
>  static int amd_iommu_def_domain_type(struct device *dev)
>  {
>  	struct iommu_dev_data *dev_data;
> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>  	if (!dev_data)
>  		return 0;
>  
> +	if (!dev_is_pci(dev))
> +		return 0;
> +
>  	/* Always use DMA domain for untrusted device */
> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
> +	if (to_pci_dev(dev)->untrusted)
>  		return IOMMU_DOMAIN_DMA;
>  
> -	/*
> -	 * Do not identity map IOMMUv2 capable devices when:
> -	 *  - memory encryption is active, because some of those devices
> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
> -	 *    and require remapping.
> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
> -	 */
> -	if (pdev_pasid_supported(dev_data) &&
> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> -	    !amd_iommu_snp_en) {
> +	/* Apply device specific quirks */
> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
> +
> +		/*
> +		 * When memory encryption is active, some of these devices
> +		 * don't have the encryption bit in their DMA-mask and
> +		 * require remapping.
> +		 */
> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> +			return 0;
> +
> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
> +		if (amd_iommu_snp_en)
> +			return 0;
> +
>  		return IOMMU_DOMAIN_IDENTITY;
>  	}
>  
> -- 
> 2.31.1
> 

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Ankit,


On 7/23/2026 9:23 PM, Ankit Soni wrote:
> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>> using PASID check. It worked fine as most GPU's has PASID feature. But
>> this means, identity mode enforcement is done for all PASID capable devices.
>>
>> Previously it made sense as domain allocation API
>> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
>> check device capability and decide best suited page table type (v1 or
>> v2). With recent enhancement to driver code, it uses
>> domain_alloc_paging_flags() ops for all paging mode domain allocation.
>> This can check device/flags and allocate best suited page table (v1 or v2).
>> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
>> GPUs only.
>>
>> With this change system booted with DMA translation mode will select:
>>  * Guest (v2) page table for PASID capable device
>>  * Host (v1) page table for non-PASID capable device
>>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
>> ---
>>  drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>>  1 file changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>> index 563f9c2672d5..fe642e33c87d 100644
>> --- a/drivers/iommu/amd/iommu.c
>> +++ b/drivers/iommu/amd/iommu.c
>> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
>>  	return dev_data->defer_attach;
>>  }
>>  
>> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>> +{
>> +	struct pci_dev *root_port;
>> +	int class = pdev->class >> 8;
>> +
>> +	/* AMD GPU vendor ID */
>> +	if (pdev->vendor != PCI_VENDOR_ID_ATI)
>> +		return false;
>> +
>> +	/* GPU class */
>> +	if (class != PCI_CLASS_DISPLAY_VGA &&
>> +	    class != PCI_CLASS_DISPLAY_OTHER)
>> +		return false;
>> +
>> +	root_port = pcie_find_root_port(pdev);
>> +	if (!root_port)
>> +		return false;
>> +
>> +	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */
>> +	if (root_port->vendor != PCI_VENDOR_ID_ATI)
>> +		return true;
> 
> Hi Vasant,
> 
> For a discrete GPU, pcie_find_root_port() may walk up to the system root port. 
> On an AMD platform that root port is vendored PCI_VENDOR_ID_AMD, which is not ATI. 

We want to filter based on vendor as ATI only. As Mario pointed out, logic got
inverted. Will fix it in v2.

-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Bjorn Helgaas]

On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
> Certain AMD GPU's must always be in identity mode. Currently its enforced
> using PASID check. It worked fine as most GPU's has PASID feature. But
> this means, identity mode enforcement is done for all PASID capable devices.

I think it would be useful to know something about *why* these devices
require identity mode.  And what happens without identity mode, i.e., is
there a user-visible symptom that happens when the wrong mode is used?

Since the code doesn't test any feature bits, I assume it's because these
devices have some hardware defect?

s/GPU's/GPUs/ (twice)
s/Currently its/Currently it's/
s/has PASID/have PASID/

> Previously it made sense as domain allocation API
> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
> check device capability and decide best suited page table type (v1 or
> v2). With recent enhancement to driver code, it uses
> domain_alloc_paging_flags() ops for all paging mode domain allocation.
> This can check device/flags and allocate best suited page table (v1 or v2).
> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
> GPUs only.
> 
> With this change system booted with DMA translation mode will select:
>  * Guest (v2) page table for PASID capable device
>  * Host (v1) page table for non-PASID capable device
> 
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
> ---
>  drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>  1 file changed, 45 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 563f9c2672d5..fe642e33c87d 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
>  	return dev_data->defer_attach;
>  }
>  
> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
> +{
> +	struct pci_dev *root_port;
> +	int class = pdev->class >> 8;
> +
> +	/* AMD GPU vendor ID */
> +	if (pdev->vendor != PCI_VENDOR_ID_ATI)
> +		return false;
> +
> +	/* GPU class */
> +	if (class != PCI_CLASS_DISPLAY_VGA &&
> +	    class != PCI_CLASS_DISPLAY_OTHER)
> +		return false;
> +
> +	root_port = pcie_find_root_port(pdev);
> +	if (!root_port)
> +		return false;
> +
> +	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */

s/its/it's/  "it's" == "it is"; "its" shows ownership

> +	if (root_port->vendor != PCI_VENDOR_ID_ATI)
> +		return true;
> +
> +	/* Rest all are dGPUs and works fine with DMA mode */
> +	return false;
> +}
> +
>  static int amd_iommu_def_domain_type(struct device *dev)
>  {
>  	struct iommu_dev_data *dev_data;
> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>  	if (!dev_data)
>  		return 0;
>  
> +	if (!dev_is_pci(dev))
> +		return 0;
> +
>  	/* Always use DMA domain for untrusted device */
> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
> +	if (to_pci_dev(dev)->untrusted)
>  		return IOMMU_DOMAIN_DMA;

This seems to apply a different rule to untrusted (e.g., removable) devices
based on the topology, not the device itself.  What if one of these devices
is used as an eGPU and thus uses IOMMU_DOMAIN_DMA when it really needs
IOMMU_DOMAIN_IDENTITY?

> -	/*
> -	 * Do not identity map IOMMUv2 capable devices when:
> -	 *  - memory encryption is active, because some of those devices
> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
> -	 *    and require remapping.
> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
> -	 */
> -	if (pdev_pasid_supported(dev_data) &&
> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> -	    !amd_iommu_snp_en) {
> +	/* Apply device specific quirks */
> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
> +
> +		/*
> +		 * When memory encryption is active, some of these devices
> +		 * don't have the encryption bit in their DMA-mask and
> +		 * require remapping.
> +		 */
> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> +			return 0;
> +
> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
> +		if (amd_iommu_snp_en)
> +			return 0;
> +
>  		return IOMMU_DOMAIN_IDENTITY;
>  	}
>  
> -- 
> 2.31.1
> 

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

On 7/23/26 10:59, Bjorn Helgaas wrote:
> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>> using PASID check. It worked fine as most GPU's has PASID feature. But
>> this means, identity mode enforcement is done for all PASID capable devices.
> 
> I think it would be useful to know something about *why* these devices
> require identity mode.  And what happens without identity mode, i.e., is
> there a user-visible symptom that happens when the wrong mode is used?
> 
> Since the code doesn't test any feature bits, I assume it's because these
> devices have some hardware defect?
> 
> s/GPU's/GPUs/ (twice)
> s/Currently its/Currently it's/
> s/has PASID/have PASID/
> 
>> Previously it made sense as domain allocation API
>> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
>> check device capability and decide best suited page table type (v1 or
>> v2). With recent enhancement to driver code, it uses
>> domain_alloc_paging_flags() ops for all paging mode domain allocation.
>> This can check device/flags and allocate best suited page table (v1 or v2).
>> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
>> GPUs only.
>>
>> With this change system booted with DMA translation mode will select:
>>   * Guest (v2) page table for PASID capable device
>>   * Host (v1) page table for non-PASID capable device
>>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
>> ---
>>   drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>>   1 file changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>> index 563f9c2672d5..fe642e33c87d 100644
>> --- a/drivers/iommu/amd/iommu.c
>> +++ b/drivers/iommu/amd/iommu.c
>> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
>>   	return dev_data->defer_attach;
>>   }
>>   
>> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>> +{
>> +	struct pci_dev *root_port;
>> +	int class = pdev->class >> 8;
>> +
>> +	/* AMD GPU vendor ID */
>> +	if (pdev->vendor != PCI_VENDOR_ID_ATI)
>> +		return false;
>> +
>> +	/* GPU class */
>> +	if (class != PCI_CLASS_DISPLAY_VGA &&
>> +	    class != PCI_CLASS_DISPLAY_OTHER)
>> +		return false;
>> +
>> +	root_port = pcie_find_root_port(pdev);
>> +	if (!root_port)
>> +		return false;
>> +
>> +	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */
> 
> s/its/it's/  "it's" == "it is"; "its" shows ownership
> 
>> +	if (root_port->vendor != PCI_VENDOR_ID_ATI)
>> +		return true;

This logic I believe is wrong.  You're trying to look at the parent of 
the display device (which is an internal PCIe switch for a dGPU).

You basically want a similar implementation to 
amdgpu_device_find_parent() which figures out first device outside of 
the dGPU.

>> +
>> +	/* Rest all are dGPUs and works fine with DMA mode */
>> +	return false;

Mostly for code flow, I think it would make sense the 
force_identity_mapping fallback is purely for APU.

IE something like this:

if (vendor != PCI_VENDOR_ATI)
	return false;
if (class != display)
	return false;
if (pci_upstream_bridge()->vendor == PCI_VENDOR_ATI)
	return false;

/* rest are APUs, force identity */
return true;

>> +}
>> +
>>   static int amd_iommu_def_domain_type(struct device *dev)
>>   {
>>   	struct iommu_dev_data *dev_data;
>> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>>   	if (!dev_data)
>>   		return 0;
>>   
>> +	if (!dev_is_pci(dev))
>> +		return 0;
>> +
>>   	/* Always use DMA domain for untrusted device */
>> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>> +	if (to_pci_dev(dev)->untrusted)
>>   		return IOMMU_DOMAIN_DMA;
> 
> This seems to apply a different rule to untrusted (e.g., removable) devices
> based on the topology, not the device itself.  What if one of these devices
> is used as an eGPU and thus uses IOMMU_DOMAIN_DMA when it really needs
> IOMMU_DOMAIN_IDENTITY?

I believe the identity domain mapping is only needed for APUs, which 
can't be put into an eGPU enclosure.

> 
>> -	/*
>> -	 * Do not identity map IOMMUv2 capable devices when:
>> -	 *  - memory encryption is active, because some of those devices
>> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
>> -	 *    and require remapping.
>> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
>> -	 */
>> -	if (pdev_pasid_supported(dev_data) &&
>> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
>> -	    !amd_iommu_snp_en) {
>> +	/* Apply device specific quirks */
>> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
>> +
>> +		/*
>> +		 * When memory encryption is active, some of these devices
>> +		 * don't have the encryption bit in their DMA-mask and
>> +		 * require remapping.
>> +		 */
>> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> +			return 0;
>> +
>> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
>> +		if (amd_iommu_snp_en)
>> +			return 0;
>> +
>>   		return IOMMU_DOMAIN_IDENTITY;
>>   	}
>>   
>> -- 
>> 2.31.1
>>

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Mario,


On 7/23/2026 9:41 PM, Mario Limonciello wrote:
> 
> 
> On 7/23/26 10:59, Bjorn Helgaas wrote:
>> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>>> using PASID check. It worked fine as most GPU's has PASID feature. But
>>> this means, identity mode enforcement is done for all PASID capable devices.
>>
>> I think it would be useful to know something about *why* these devices
>> require identity mode.  And what happens without identity mode, i.e., is
>> there a user-visible symptom that happens when the wrong mode is used?
>>
>> Since the code doesn't test any feature bits, I assume it's because these
>> devices have some hardware defect?
>>
>> s/GPU's/GPUs/ (twice)
>> s/Currently its/Currently it's/
>> s/has PASID/have PASID/
>>
>>> Previously it made sense as domain allocation API
>>> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
>>> check device capability and decide best suited page table type (v1 or
>>> v2). With recent enhancement to driver code, it uses
>>> domain_alloc_paging_flags() ops for all paging mode domain allocation.
>>> This can check device/flags and allocate best suited page table (v1 or v2).
>>> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
>>> GPUs only.
>>>
>>> With this change system booted with DMA translation mode will select:
>>>   * Guest (v2) page table for PASID capable device
>>>   * Host (v1) page table for non-PASID capable device
>>>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>>> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
>>> ---
>>>   drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>>>   1 file changed, 45 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>>> index 563f9c2672d5..fe642e33c87d 100644
>>> --- a/drivers/iommu/amd/iommu.c
>>> +++ b/drivers/iommu/amd/iommu.c
>>> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device
>>> *dev)
>>>       return dev_data->defer_attach;
>>>   }
>>>   +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>>> +{
>>> +    struct pci_dev *root_port;
>>> +    int class = pdev->class >> 8;
>>> +
>>> +    /* AMD GPU vendor ID */
>>> +    if (pdev->vendor != PCI_VENDOR_ID_ATI)
>>> +        return false;
>>> +
>>> +    /* GPU class */
>>> +    if (class != PCI_CLASS_DISPLAY_VGA &&
>>> +        class != PCI_CLASS_DISPLAY_OTHER)
>>> +        return false;
>>> +
>>> +    root_port = pcie_find_root_port(pdev);
>>> +    if (!root_port)
>>> +        return false;
>>> +
>>> +    /* If bridge vendor is not ATI then its APU and force IDENTITY mode */
>>
>> s/its/it's/  "it's" == "it is"; "its" shows ownership
>>
>>> +    if (root_port->vendor != PCI_VENDOR_ID_ATI)
>>> +        return true;
> 
> This logic I believe is wrong.  You're trying to look at the parent of the
> display device (which is an internal PCIe switch for a dGPU).

You are right. It got inverted while I was fine tuning the code.

> 
> You basically want a similar implementation to amdgpu_device_find_parent() which
> figures out first device outside of the dGPU.

Ack.

> 
>>> +
>>> +    /* Rest all are dGPUs and works fine with DMA mode */
>>> +    return false;
> 
> Mostly for code flow, I think it would make sense the force_identity_mapping
> fallback is purely for APU.
> 
> IE something like this:
> 
> if (vendor != PCI_VENDOR_ATI)
>     return false;
> if (class != display)
>     return false;
> if (pci_upstream_bridge()->vendor == PCI_VENDOR_ATI)
>     return false;
> 
> /* rest are APUs, force identity */
> return true;

Makes sense. And pci_upstream_bridge() return NULL, then return true? (something
like below) ?

+static bool quirks_force_identity_mapping(struct pci_dev *pdev)
+{
+       struct pci_dev *root_port;
+       int class = pdev->class >> 8;
+
+       /* AMD GPU vendor ID */
+       if (pdev->vendor != PCI_VENDOR_ID_ATI)
+               return false;
+
+       /* GPU class */
+       if (class != PCI_CLASS_DISPLAY_VGA &&
+           class != PCI_CLASS_DISPLAY_OTHER)
+               return false;
+
+       if (pci_upstream_bridge(pdev) &&
+           pci_upstream_bridge(pdev)->vendor == PCI_VENDOR_ID_ATI)
+               return false;
+
+       return true;
+}
+

-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

On 7/23/26 11:23, Vasant Hegde wrote:
> Mario,
> 
> 
> On 7/23/2026 9:41 PM, Mario Limonciello wrote:
>>
>>
>> On 7/23/26 10:59, Bjorn Helgaas wrote:
>>> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>>>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>>>> using PASID check. It worked fine as most GPU's has PASID feature. But
>>>> this means, identity mode enforcement is done for all PASID capable devices.
>>>
>>> I think it would be useful to know something about *why* these devices
>>> require identity mode.  And what happens without identity mode, i.e., is
>>> there a user-visible symptom that happens when the wrong mode is used?
>>>
>>> Since the code doesn't test any feature bits, I assume it's because these
>>> devices have some hardware defect?
>>>
>>> s/GPU's/GPUs/ (twice)
>>> s/Currently its/Currently it's/
>>> s/has PASID/have PASID/
>>>
>>>> Previously it made sense as domain allocation API
>>>> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
>>>> check device capability and decide best suited page table type (v1 or
>>>> v2). With recent enhancement to driver code, it uses
>>>> domain_alloc_paging_flags() ops for all paging mode domain allocation.
>>>> This can check device/flags and allocate best suited page table (v1 or v2).
>>>> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
>>>> GPUs only.
>>>>
>>>> With this change system booted with DMA translation mode will select:
>>>>    * Guest (v2) page table for PASID capable device
>>>>    * Host (v1) page table for non-PASID capable device
>>>>
>>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>>>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>>>> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
>>>> ---
>>>>    drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>>>>    1 file changed, 45 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>>>> index 563f9c2672d5..fe642e33c87d 100644
>>>> --- a/drivers/iommu/amd/iommu.c
>>>> +++ b/drivers/iommu/amd/iommu.c
>>>> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device
>>>> *dev)
>>>>        return dev_data->defer_attach;
>>>>    }
>>>>    +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>>>> +{
>>>> +    struct pci_dev *root_port;
>>>> +    int class = pdev->class >> 8;
>>>> +
>>>> +    /* AMD GPU vendor ID */
>>>> +    if (pdev->vendor != PCI_VENDOR_ID_ATI)
>>>> +        return false;
>>>> +
>>>> +    /* GPU class */
>>>> +    if (class != PCI_CLASS_DISPLAY_VGA &&
>>>> +        class != PCI_CLASS_DISPLAY_OTHER)
>>>> +        return false;
>>>> +
>>>> +    root_port = pcie_find_root_port(pdev);
>>>> +    if (!root_port)
>>>> +        return false;
>>>> +
>>>> +    /* If bridge vendor is not ATI then its APU and force IDENTITY mode */
>>>
>>> s/its/it's/  "it's" == "it is"; "its" shows ownership
>>>
>>>> +    if (root_port->vendor != PCI_VENDOR_ID_ATI)
>>>> +        return true;
>>
>> This logic I believe is wrong.  You're trying to look at the parent of the
>> display device (which is an internal PCIe switch for a dGPU).
> 
> You are right. It got inverted while I was fine tuning the code.
> 
>>
>> You basically want a similar implementation to amdgpu_device_find_parent() which
>> figures out first device outside of the dGPU.
> 
> Ack.
> 
>>
>>>> +
>>>> +    /* Rest all are dGPUs and works fine with DMA mode */
>>>> +    return false;
>>
>> Mostly for code flow, I think it would make sense the force_identity_mapping
>> fallback is purely for APU.
>>
>> IE something like this:
>>
>> if (vendor != PCI_VENDOR_ATI)
>>      return false;
>> if (class != display)
>>      return false;
>> if (pci_upstream_bridge()->vendor == PCI_VENDOR_ATI)
>>      return false;
>>
>> /* rest are APUs, force identity */
>> return true;
> 
> Makes sense. And pci_upstream_bridge() return NULL, then return true? (something
> like below) ?

Bascially; yeah.  But one comment below.

> 
> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
> +{
> +       struct pci_dev *root_port;
> +       int class = pdev->class >> 8;
> +
> +       /* AMD GPU vendor ID */
> +       if (pdev->vendor != PCI_VENDOR_ID_ATI)
> +               return false;
> +
> +       /* GPU class */
> +       if (class != PCI_CLASS_DISPLAY_VGA &&
> +           class != PCI_CLASS_DISPLAY_OTHER)
> +               return false;
> +
> +       if (pci_upstream_bridge(pdev) &&

I don't think you need to check for pci_upstream_bridge() to be 
non-NULL.  You already checked that it's an endpoint by looking at the 
class.  So an endpoint will be connected to a bridge of some sort 
(either a switch internal to the dGPU or to a root port).

> +           pci_upstream_bridge(pdev)->vendor == PCI_VENDOR_ID_ATI)
> +               return false;
> +

Make sure you leave a comment here about what true means (/* it is the 
GPU in an APU */) so that if we need to add more cases later it's 
obvious without having to dig up this thread again.

> +       return true;
> +}
> +
> 
> -Vasant
> 

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Mario,


On 7/23/2026 10:02 PM, Mario Limonciello wrote:
> 
> 
> On 7/23/26 11:23, Vasant Hegde wrote:
>> Mario,
>>
>>
>> On 7/23/2026 9:41 PM, Mario Limonciello wrote:
>>>
>>>
>>> On 7/23/26 10:59, Bjorn Helgaas wrote:
>>>> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>>>>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>>>>> using PASID check. It worked fine as most GPU's has PASID feature. But
>>>>> this means, identity mode enforcement is done for all PASID capable devices.
>>>>
>>>> I think it would be useful to know something about *why* these devices
>>>> require identity mode.  And what happens without identity mode, i.e., is
>>>> there a user-visible symptom that happens when the wrong mode is used?
>>>>
>>>> Since the code doesn't test any feature bits, I assume it's because these
>>>> devices have some hardware defect?
>>>>
>>>> s/GPU's/GPUs/ (twice)


.../...

>>
>> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>> +{
>> +       struct pci_dev *root_port;
>> +       int class = pdev->class >> 8;
>> +
>> +       /* AMD GPU vendor ID */
>> +       if (pdev->vendor != PCI_VENDOR_ID_ATI)
>> +               return false;
>> +
>> +       /* GPU class */
>> +       if (class != PCI_CLASS_DISPLAY_VGA &&
>> +           class != PCI_CLASS_DISPLAY_OTHER)
>> +               return false;
>> +
>> +       if (pci_upstream_bridge(pdev) &&
> 
> I don't think you need to check for pci_upstream_bridge() to be non-NULL.  You
> already checked that it's an endpoint by looking at the class.  So an endpoint
> will be connected to a bridge of some sort (either a switch internal to the dGPU
> or to a root port).

Ok will fix it .

> 
>> +           pci_upstream_bridge(pdev)->vendor == PCI_VENDOR_ID_ATI)
>> +               return false;
>> +
> 
> Make sure you leave a comment here about what true means (/* it is the GPU in an
> APU */) so that if we need to add more cases later it's obvious without having
> to dig up this thread again.

Sure.


-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Bjorn Helgaas]

On Thu, Jul 23, 2026 at 11:32:49AM -0500, Mario Limonciello wrote:
> On 7/23/26 11:23, Vasant Hegde wrote:
> > On 7/23/2026 9:41 PM, Mario Limonciello wrote:
> > > On 7/23/26 10:59, Bjorn Helgaas wrote:
> > > > On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
> > > > > Certain AMD GPU's must always be in identity mode. Currently its enforced
> > > > > using PASID check. It worked fine as most GPU's has PASID feature. But
> > > > > this means, identity mode enforcement is done for all PASID capable devices.
> ...

> > +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
> > +{
> > +       struct pci_dev *root_port;
> > +       int class = pdev->class >> 8;
> > +
> > +       /* AMD GPU vendor ID */
> > +       if (pdev->vendor != PCI_VENDOR_ID_ATI)
> > +               return false;
> > +
> > +       /* GPU class */
> > +       if (class != PCI_CLASS_DISPLAY_VGA &&
> > +           class != PCI_CLASS_DISPLAY_OTHER)
> > +               return false;
> > +
> > +       if (pci_upstream_bridge(pdev) &&
> 
> I don't think you need to check for pci_upstream_bridge() to be
> non-NULL.  You already checked that it's an endpoint by looking at
> the class.  So an endpoint will be connected to a bridge of some
> sort (either a switch internal to the dGPU or to a root port).

I think devices can be passed through to virtualized guests with no
upstream bridge visible to the guest, can't they?

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

On 7/23/26 14:53, Bjorn Helgaas wrote:
> On Thu, Jul 23, 2026 at 11:32:49AM -0500, Mario Limonciello wrote:
>> On 7/23/26 11:23, Vasant Hegde wrote:
>>> On 7/23/2026 9:41 PM, Mario Limonciello wrote:
>>>> On 7/23/26 10:59, Bjorn Helgaas wrote:
>>>>> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>>>>>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>>>>>> using PASID check. It worked fine as most GPU's has PASID feature. But
>>>>>> this means, identity mode enforcement is done for all PASID capable devices.
>> ...
> 
>>> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>>> +{
>>> +       struct pci_dev *root_port;
>>> +       int class = pdev->class >> 8;
>>> +
>>> +       /* AMD GPU vendor ID */
>>> +       if (pdev->vendor != PCI_VENDOR_ID_ATI)
>>> +               return false;
>>> +
>>> +       /* GPU class */
>>> +       if (class != PCI_CLASS_DISPLAY_VGA &&
>>> +           class != PCI_CLASS_DISPLAY_OTHER)
>>> +               return false;
>>> +
>>> +       if (pci_upstream_bridge(pdev) &&
>>
>> I don't think you need to check for pci_upstream_bridge() to be
>> non-NULL.  You already checked that it's an endpoint by looking at
>> the class.  So an endpoint will be connected to a bridge of some
>> sort (either a switch internal to the dGPU or to a root port).
> 
> I think devices can be passed through to virtualized guests with no
> upstream bridge visible to the guest, can't they?

None of the GPUs in APUs support SRIOV, so there isn't a VF to be passed 
in to a guest.  But I guess you could pass the whole endpoint in.

When passed into a guest doesn't it end up associated behind a root port 
in the guest though?

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Bjorn Helgaas]

[+cc Gerd, Alex]

On Thu, Jul 23, 2026 at 02:58:14PM -0500, Mario Limonciello wrote:
> On 7/23/26 14:53, Bjorn Helgaas wrote:
> > On Thu, Jul 23, 2026 at 11:32:49AM -0500, Mario Limonciello wrote:
> > > On 7/23/26 11:23, Vasant Hegde wrote:
> > > > On 7/23/2026 9:41 PM, Mario Limonciello wrote:
> > > > > On 7/23/26 10:59, Bjorn Helgaas wrote:
> > > > > > On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
> > > > > > > Certain AMD GPU's must always be in identity mode. Currently its enforced
> > > > > > > using PASID check. It worked fine as most GPU's has PASID feature. But
> > > > > > > this means, identity mode enforcement is done for all PASID capable devices.
> > > ...
> > 
> > > > +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
> > > > +{
> > > > +       struct pci_dev *root_port;
> > > > +       int class = pdev->class >> 8;
> > > > +
> > > > +       /* AMD GPU vendor ID */
> > > > +       if (pdev->vendor != PCI_VENDOR_ID_ATI)
> > > > +               return false;
> > > > +
> > > > +       /* GPU class */
> > > > +       if (class != PCI_CLASS_DISPLAY_VGA &&
> > > > +           class != PCI_CLASS_DISPLAY_OTHER)
> > > > +               return false;
> > > > +
> > > > +       if (pci_upstream_bridge(pdev) &&
> > > 
> > > I don't think you need to check for pci_upstream_bridge() to be
> > > non-NULL.  You already checked that it's an endpoint by looking at
> > > the class.  So an endpoint will be connected to a bridge of some
> > > sort (either a switch internal to the dGPU or to a root port).
> > 
> > I think devices can be passed through to virtualized guests with
> > no upstream bridge visible to the guest, can't they?
> 
> None of the GPUs in APUs support SRIOV, so there isn't a VF to be
> passed in to a guest.  But I guess you could pass the whole endpoint
> in.
> 
> When passed into a guest doesn't it end up associated behind a root
> port in the guest though?

I don't think the Root Port is always passed into the guest.  From
1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports
them"):

  On s390 and many virtualized guests, the Endpoint is visible but the
  Root Port is not.  In this case, pci_enable_atomic_ops_to_root()
  previously enabled AtomicOps in the Endpoint even though it can't
  tell whether the Root Port supports them as a completer.

Maybe Alex will chime in and tell us more about non-s390 guests.

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Jason Gunthorpe]

On Thu, Jul 23, 2026 at 04:02:46PM -0500, Bjorn Helgaas wrote:
> I don't think the Root Port is always passed into the guest.  From
> 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports
> them"):

If this device has broken support for iommu translation entirely then
vfio is unsuably broken too. The right answer is to refuse to attach a
paging domain to such a device, I think this patch series should be
enhanced to include this.

Like a qurik that says translation is broken and then def domain is
changed and paging attach will fail

Jason

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

On 7/24/2026 8:41 PM, Jason Gunthorpe wrote:
> On Thu, Jul 23, 2026 at 04:02:46PM -0500, Bjorn Helgaas wrote:
>> I don't think the Root Port is always passed into the guest.  From
>> 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports
>> them"):
> 
> If this device has broken support for iommu translation entirely then
> vfio is unsuably broken too. The right answer is to refuse to attach a
> paging domain to such a device, I think this patch series should be
> enhanced to include this.
> > Like a qurik that says translation is broken and then def domain is
> changed and paging attach will fail

Yeah. We can add check i domain allocation path as well.

-Vasant



> 
> Jason

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Bjorn,


On 7/23/2026 9:29 PM, Bjorn Helgaas wrote:
> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>> Certain AMD GPU's must always be in identity mode. Currently its enforced
>> using PASID check. It worked fine as most GPU's has PASID feature. But
>> this means, identity mode enforcement is done for all PASID capable devices.
> 
> I think it would be useful to know something about *why* these devices
> require identity mode.  And what happens without identity mode, i.e., is
> there a user-visible symptom that happens when the wrong mode is used?

I will have to check with Alex for the details. Will check with him.

> 
> Since the code doesn't test any feature bits, I assume it's because these
> devices have some hardware defect?
> 
> s/GPU's/GPUs/ (twice)
> s/Currently its/Currently it's/
> s/has PASID/have PASID/

Ack. Will fix it in v2.

> 
>> Previously it made sense as domain allocation API
>> (iommu_ops->domain_alloc()) was just passing domain type. So it couldn't
>> check device capability and decide best suited page table type (v1 or
>> v2). With recent enhancement to driver code, it uses
>> domain_alloc_paging_flags() ops for all paging mode domain allocation.
>> This can check device/flags and allocate best suited page table (v1 or v2).
>> Hence fix amd_iommu_def_domain_type() to force identity mapping for selected
>> GPUs only.
>>
>> With this change system booted with DMA translation mode will select:
>>  * Guest (v2) page table for PASID capable device
>>  * Host (v1) page table for non-PASID capable device
>>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>> Tested-by: Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
>> ---
>>  drivers/iommu/amd/iommu.c | 56 +++++++++++++++++++++++++++++++--------
>>  1 file changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>> index 563f9c2672d5..fe642e33c87d 100644
>> --- a/drivers/iommu/amd/iommu.c
>> +++ b/drivers/iommu/amd/iommu.c
>> @@ -3112,6 +3112,32 @@ static bool amd_iommu_is_attach_deferred(struct device *dev)
>>  	return dev_data->defer_attach;
>>  }
>>  
>> +static bool quirks_force_identity_mapping(struct pci_dev *pdev)
>> +{
>> +	struct pci_dev *root_port;
>> +	int class = pdev->class >> 8;
>> +
>> +	/* AMD GPU vendor ID */
>> +	if (pdev->vendor != PCI_VENDOR_ID_ATI)
>> +		return false;
>> +
>> +	/* GPU class */
>> +	if (class != PCI_CLASS_DISPLAY_VGA &&
>> +	    class != PCI_CLASS_DISPLAY_OTHER)
>> +		return false;
>> +
>> +	root_port = pcie_find_root_port(pdev);
>> +	if (!root_port)
>> +		return false;
>> +
>> +	/* If bridge vendor is not ATI then its APU and force IDENTITY mode */
> 
> s/its/it's/  "it's" == "it is"; "its" shows ownership

Ack. Will fix it in v2.

> 
>> +	if (root_port->vendor != PCI_VENDOR_ID_ATI)
>> +		return true;
>> +
>> +	/* Rest all are dGPUs and works fine with DMA mode */
>> +	return false;
>> +}
>> +
>>  static int amd_iommu_def_domain_type(struct device *dev)
>>  {
>>  	struct iommu_dev_data *dev_data;
>> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>>  	if (!dev_data)
>>  		return 0;
>>  
>> +	if (!dev_is_pci(dev))
>> +		return 0;
>> +
>>  	/* Always use DMA domain for untrusted device */
>> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>> +	if (to_pci_dev(dev)->untrusted)
>>  		return IOMMU_DOMAIN_DMA;
> 
> This seems to apply a different rule to untrusted (e.g., removable) devices
> based on the topology, not the device itself.  What if one of these devices
> is used as an eGPU and thus uses IOMMU_DOMAIN_DMA when it really needs
> IOMMU_DOMAIN_IDENTITY?

I tried to keep the existing order (untested followed by GPU check). As Mario
commented, we need identity for APU only. So this is fine.

-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Jason Gunthorpe]

On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>  	if (!dev_data)
>  		return 0;
>  
> +	if (!dev_is_pci(dev))
> +		return 0;
> +
>  	/* Always use DMA domain for untrusted device */
> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
> +	if (to_pci_dev(dev)->untrusted)
>  		return IOMMU_DOMAIN_DMA;

The core code does this, it shouldn't be in a driver?

> -	/*
> -	 * Do not identity map IOMMUv2 capable devices when:
> -	 *  - memory encryption is active, because some of those devices
> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
> -	 *    and require remapping.
> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
> -	 */
> -	if (pdev_pasid_supported(dev_data) &&
> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> -	    !amd_iommu_snp_en) {
> +	/* Apply device specific quirks */
> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
> +
> +		/*
> +		 * When memory encryption is active, some of these devices
> +		 * don't have the encryption bit in their DMA-mask and
> +		 * require remapping.
> +		 */
> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> +			return 0;

I think this can probably be dropped now? There is no intersection of
this old broken embedded GPU and a CPU that supports CC right?

> +
> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
> +		if (amd_iommu_snp_en)
> +			return 0;

Ditto?

Jason

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

On 7/24/2026 8:45 PM, Jason Gunthorpe wrote:
> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>>  	if (!dev_data)
>>  		return 0;
>>  
>> +	if (!dev_is_pci(dev))
>> +		return 0;
>> +
>>  	/* Always use DMA domain for untrusted device */
>> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>> +	if (to_pci_dev(dev)->untrusted)
>>  		return IOMMU_DOMAIN_DMA;
> 
> The core code does this, it shouldn't be in a driver?

Right. I didn't realized core has this check. I will drop this check in next
version.

> 
>> -	/*
>> -	 * Do not identity map IOMMUv2 capable devices when:
>> -	 *  - memory encryption is active, because some of those devices
>> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
>> -	 *    and require remapping.
>> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
>> -	 */
>> -	if (pdev_pasid_supported(dev_data) &&
>> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
>> -	    !amd_iommu_snp_en) {
>> +	/* Apply device specific quirks */
>> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
>> +
>> +		/*
>> +		 * When memory encryption is active, some of these devices
>> +		 * don't have the encryption bit in their DMA-mask and
>> +		 * require remapping.
>> +		 */
>> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> +			return 0;
> 
> I think this can probably be dropped now? There is no intersection of
> this old broken embedded GPU and a CPU that supports CC right?


I did consider dropping these two checks, but I was not entirely sure. So I kept
as is for now. Once these series settles and I can go with next step of dropping
these two checks.

@Alex, @Mario, Any suggestions ?

-Vasant

> 
>> +
>> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
>> +		if (amd_iommu_snp_en)
>> +			return 0;
> 
> Ditto?
> 
> Jason

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

On 7/26/26 23:19, Vasant Hegde wrote:
> 
> 
> On 7/24/2026 8:45 PM, Jason Gunthorpe wrote:
>> On Thu, Jul 23, 2026 at 06:15:48AM +0000, Vasant Hegde wrote:
>>> @@ -3120,20 +3146,28 @@ static int amd_iommu_def_domain_type(struct device *dev)
>>>   	if (!dev_data)
>>>   		return 0;
>>>   
>>> +	if (!dev_is_pci(dev))
>>> +		return 0;
>>> +
>>>   	/* Always use DMA domain for untrusted device */
>>> -	if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>>> +	if (to_pci_dev(dev)->untrusted)
>>>   		return IOMMU_DOMAIN_DMA;
>>
>> The core code does this, it shouldn't be in a driver?
> 
> Right. I didn't realized core has this check. I will drop this check in next
> version.
> 
>>
>>> -	/*
>>> -	 * Do not identity map IOMMUv2 capable devices when:
>>> -	 *  - memory encryption is active, because some of those devices
>>> -	 *    (AMD GPUs) don't have the encryption bit in their DMA-mask
>>> -	 *    and require remapping.
>>> -	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
>>> -	 */
>>> -	if (pdev_pasid_supported(dev_data) &&
>>> -	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
>>> -	    !amd_iommu_snp_en) {
>>> +	/* Apply device specific quirks */
>>> +	if (quirks_force_identity_mapping(to_pci_dev(dev))) {
>>> +
>>> +		/*
>>> +		 * When memory encryption is active, some of these devices
>>> +		 * don't have the encryption bit in their DMA-mask and
>>> +		 * require remapping.
>>> +		 */
>>> +		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>>> +			return 0;
>>
>> I think this can probably be dropped now? There is no intersection of
>> this old broken embedded GPU and a CPU that supports CC right?
> 
> 
> I did consider dropping these two checks, but I was not entirely sure. So I kept
> as is for now. Once these series settles and I can go with next step of dropping
> these two checks.
> 
> @Alex, @Mario, Any suggestions ?
> 

The background comes from this series:

https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/

> -Vasant
> 
>>
>>> +
>>> +		/* DTE[Mode]=0 is prohibited when SNP is enabled */
>>> +		if (amd_iommu_snp_en)
>>> +			return 0;
>>
>> Ditto?
>>
>> Jason
> 

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Mario,


On 7/27/2026 8:15 PM, Mario Limonciello wrote:
> 
> 
> On 7/26/26 23:19, Vasant Hegde wrote:
>>
>>

.../...

>>>
>>> I think this can probably be dropped now? There is no intersection of
>>> this old broken embedded GPU and a CPU that supports CC right?
>>
>>
>> I did consider dropping these two checks, but I was not entirely sure. So I kept
>> as is for now. Once these series settles and I can go with next step of dropping
>> these two checks.
>>
>> @Alex, @Mario, Any suggestions ?
>>
> 
> The background comes from this series:
> 
> https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/


Thanks for old link. So it looks like we are good to drop SME check?

Also is it safe to assume SNP is not enabled on these platform and drop that
check? Anyway SNP requirement (which doesn't support identity mapping) and APU
requirement (needs identity mapping) is conflicting.


-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

+Felix

On 7/27/26 23:52, Vasant Hegde wrote:
> Mario,
> 
> 
> On 7/27/2026 8:15 PM, Mario Limonciello wrote:
>>
>>
>> On 7/26/26 23:19, Vasant Hegde wrote:
>>>
>>>
> 
> .../...
> 
>>>>
>>>> I think this can probably be dropped now? There is no intersection of
>>>> this old broken embedded GPU and a CPU that supports CC right?
>>>
>>>
>>> I did consider dropping these two checks, but I was not entirely sure. So I kept
>>> as is for now. Once these series settles and I can go with next step of dropping
>>> these two checks.
>>>
>>> @Alex, @Mario, Any suggestions ?
>>>
>>
>> The background comes from this series:
>>
>> https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/
> 
> 
> Thanks for old link. So it looks like we are good to drop SME check?

Yeah I think so.

> 
> Also is it safe to assume SNP is not enabled on these platform and drop that
> check? Anyway SNP requirement (which doesn't support identity mapping) and APU
> requirement (needs identity mapping) is conflicting.
> 

The current platforms I think this is a safe assumption.

Felix,

Can we revisit the requirement of identity mapping for APU?  Does it 
still hold with the current hardware and software?

I'm wondering if we can just apply it to Raven and loosen up elsewhere 
and what gives if we do that.

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Kuehling, Felix]

On 2026-07-28 01:31, Mario Limonciello wrote:
> +Felix
>
> On 7/27/26 23:52, Vasant Hegde wrote:
>> Mario,
>>
>>
>> On 7/27/2026 8:15 PM, Mario Limonciello wrote:
>>>
>>>
>>> On 7/26/26 23:19, Vasant Hegde wrote:
>>>>
>>>>
>>
>> .../...
>>
>>>>>
>>>>> I think this can probably be dropped now? There is no intersection of
>>>>> this old broken embedded GPU and a CPU that supports CC right?
>>>>
>>>>
>>>> I did consider dropping these two checks, but I was not entirely 
>>>> sure. So I kept
>>>> as is for now. Once these series settles and I can go with next 
>>>> step of dropping
>>>> these two checks.
>>>>
>>>> @Alex, @Mario, Any suggestions ?
>>>>
>>>
>>> The background comes from this series:
>>>
>>> https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/
>>
>>
>> Thanks for old link. So it looks like we are good to drop SME check?
>
> Yeah I think so.
>
>>
>> Also is it safe to assume SNP is not enabled on these platform and 
>> drop that
>> check? Anyway SNP requirement (which doesn't support identity 
>> mapping) and APU
>> requirement (needs identity mapping) is conflicting.
>>
>
> The current platforms I think this is a safe assumption.
>
> Felix,
>
> Can we revisit the requirement of identity mapping for APU?  Does it 
> still hold with the current hardware and software?

I'm not sure what this means. Is Identity mode something like 
pass-through? I don't know why this is required on APUs. If it's related 
to IOMMUv2 support, then it's probably no longer needed. We're not using 
IOMMUv2 on our APUs any more. Support for that was removed from the 
amdgpu driver a few years ago.

Regards,
   Felix



>
> I'm wondering if we can just apply it to Raven and loosen up elsewhere 
> and what gives if we do that.

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Mario Limonciello]

On 7/28/26 14:10, Kuehling, Felix wrote:
> On 2026-07-28 01:31, Mario Limonciello wrote:
>> +Felix
>>
>> On 7/27/26 23:52, Vasant Hegde wrote:
>>> Mario,
>>>
>>>
>>> On 7/27/2026 8:15 PM, Mario Limonciello wrote:
>>>>
>>>>
>>>> On 7/26/26 23:19, Vasant Hegde wrote:
>>>>>
>>>>>
>>>
>>> .../...
>>>
>>>>>>
>>>>>> I think this can probably be dropped now? There is no intersection of
>>>>>> this old broken embedded GPU and a CPU that supports CC right?
>>>>>
>>>>>
>>>>> I did consider dropping these two checks, but I was not entirely 
>>>>> sure. So I kept
>>>>> as is for now. Once these series settles and I can go with next 
>>>>> step of dropping
>>>>> these two checks.
>>>>>
>>>>> @Alex, @Mario, Any suggestions ?
>>>>>
>>>>
>>>> The background comes from this series:
>>>>
>>>> https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/
>>>
>>>
>>> Thanks for old link. So it looks like we are good to drop SME check?
>>
>> Yeah I think so.
>>
>>>
>>> Also is it safe to assume SNP is not enabled on these platform and 
>>> drop that
>>> check? Anyway SNP requirement (which doesn't support identity 
>>> mapping) and APU
>>> requirement (needs identity mapping) is conflicting.
>>>
>>
>> The current platforms I think this is a safe assumption.
>>
>> Felix,
>>
>> Can we revisit the requirement of identity mapping for APU?  Does it 
>> still hold with the current hardware and software?
> 
> I'm not sure what this means. Is Identity mode something like pass- 
> through? I don't know why this is required on APUs. If it's related to 
> IOMMUv2 support, then it's probably no longer needed. We're not using 
> IOMMUv2 on our APUs any more. Support for that was removed from the 
> amdgpu driver a few years ago.
> 

Hmm, I just had a try with this on a few years old APU (PHX).  It's 
flicker central with this (7.2-rc5~ish tree):

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 29dc18d3d22e5..1e792cee7f4cd 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3134,19 +3134,6 @@ static int amd_iommu_def_domain_type(struct 
device *dev)
         if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
                 return IOMMU_DOMAIN_DMA;

-       /*
-        * Do not identity map IOMMUv2 capable devices when:
-        *  - memory encryption is active, because some of those devices
-        *    (AMD GPUs) don't have the encryption bit in their DMA-mask
-        *    and require remapping.
-        *  - SNP is enabled, because it prohibits DTE[Mode]=0.
-        */
-       if (pdev_pasid_supported(dev_data) &&
-           !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
-           !amd_iommu_snp_en) {
-               return IOMMU_DOMAIN_IDENTITY;
-       }
-
         return 0;
  }

The flicking is reminencent of issues moving BOs between VRAM and GTT 
from a few years ago.

So I don't think it can be dropped (just) yet.

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Mario, Alex, Felix,


On 7/29/2026 1:27 AM, Mario Limonciello wrote:
> 
> 
> On 7/28/26 14:10, Kuehling, Felix wrote:
>> On 2026-07-28 01:31, Mario Limonciello wrote:
>>> +Felix
>>>
>>> On 7/27/26 23:52, Vasant Hegde wrote:
>>>> Mario,


.../...

> 
> Hmm, I just had a try with this on a few years old APU (PHX).  It's flicker
> central with this (7.2-rc5~ish tree):
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 29dc18d3d22e5..1e792cee7f4cd 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3134,19 +3134,6 @@ static int amd_iommu_def_domain_type(struct device *dev)
>         if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>                 return IOMMU_DOMAIN_DMA;
> 
> -       /*
> -        * Do not identity map IOMMUv2 capable devices when:
> -        *  - memory encryption is active, because some of those devices
> -        *    (AMD GPUs) don't have the encryption bit in their DMA-mask
> -        *    and require remapping.
> -        *  - SNP is enabled, because it prohibits DTE[Mode]=0.
> -        */
> -       if (pdev_pasid_supported(dev_data) &&
> -           !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> -           !amd_iommu_snp_en) {
> -               return IOMMU_DOMAIN_IDENTITY;
> -       }
> -
>         return 0;
>  }
> 
> The flicking is reminencent of issues moving BOs between VRAM and GTT from a few
> years ago.
> 
> So I don't think it can be dropped (just) yet.

Based on discussion so far in this thread and the link Mario shared earlier [1]:
  - We still need identity mapping for APUs. I will fine tune the patch based on
the discussion in this thread.
  - Its fine to drop SNP check
  - I am still not sure its safe to drop SME check (CC_ATTR_MEM_ENCRYPT)
    Because here were are putting all APUs in identity mode.
    Commit ea68573d408f explicitly error out for RAVEN and some of the older APU
platform didn't support SME. But not sure about newer ones.


So I am inclined to keep SME check for now. Once this patch stabilized we can
revisit the SME check?


[1] https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/

-Vasant

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Jason Gunthorpe]

On Thu, Jul 30, 2026 at 04:56:37PM +0530, Vasant Hegde wrote:

> Based on discussion so far in this thread and the link Mario shared earlier [1]:
>   - We still need identity mapping for APUs. I will fine tune the patch based on
> the discussion in this thread.

IMHO if certain HW has broken support for PAGING (eg because it can't
handle the isochronous needs) then it should be quirked and blocked
properly.

I thought the issue here was the PASID check forcing identity and
accidently capturing these raven chips too? It should just be moved
out to a normal quirk..

>   - Its fine to drop SNP check
>   - I am still not sure its safe to drop SME check (CC_ATTR_MEM_ENCRYPT)
>     Because here were are putting all APUs in identity mode.
>     Commit ea68573d408f explicitly error out for RAVEN and some of the older APU
> platform didn't support SME. But not sure about newer ones.

That's quite a hacky check to make in that commit..

> So I am inclined to keep SME check for now. Once this patch stabilized we can
> revisit the SME check?

The SME check makes no sense either, but if you want to stage things
I'm OK with it.

Jason

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Vasant Hegde]

Jason,


On 8/5/2026 6:37 AM, Jason Gunthorpe wrote:
> On Thu, Jul 30, 2026 at 04:56:37PM +0530, Vasant Hegde wrote:
> 
>> Based on discussion so far in this thread and the link Mario shared earlier [1]:
>>   - We still need identity mapping for APUs. I will fine tune the patch based on
>> the discussion in this thread.
> 
> IMHO if certain HW has broken support for PAGING (eg because it can't
> handle the isochronous needs) then it should be quirked and blocked
> properly.
> 
> I thought the issue here was the PASID check forcing identity and
> accidently capturing these raven chips too? It should just be moved
> out to a normal quirk..
> 
>>   - Its fine to drop SNP check
>>   - I am still not sure its safe to drop SME check (CC_ATTR_MEM_ENCRYPT)
>>     Because here were are putting all APUs in identity mode.
>>     Commit ea68573d408f explicitly error out for RAVEN and some of the older APU
>> platform didn't support SME. But not sure about newer ones.
> 
> That's quite a hacky check to make in that commit..
> 
>> So I am inclined to keep SME check for now. Once this patch stabilized we can
>> revisit the SME check?
> 
> The SME check makes no sense either, but if you want to stage things
> I'm OK with it.

Right. Eventually it should remove SME as well. But I am concerned about any
regression. Also I don't have all these devices to test it. Hence for now I will
limit to APUs, keep SME check and drop SNP check. Once it settle, we can go with
next step.

I will respin the patch later this week.

-Vasant

RE: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Deucher, Alexander]

AMD General

> -----Original Message-----
> From: Hegde, Vasant <Vasant.Hegde@amd.com>
> Sent: Wednesday, August 5, 2026 10:38 AM
> To: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Limonciello, Mario <Mario.Limonciello@amd.com>; Kuehling, Felix
> <Felix.Kuehling@amd.com>; Deucher, Alexander
> <Alexander.Deucher@amd.com>; iommu@lists.linux.dev; joro@8bytes.org;
> linux-pci@vger.kernel.org; will@kernel.org; robin.murphy@arm.com;
> Suthikulpanit, Suravee <Suravee.Suthikulpanit@amd.com>;
> bhelgaas@google.com; Longia, Amandeep Kaur
> <AmandeepKaur.Longia@amd.com>
> Subject: Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs
> only
>
> Jason,
>
>
> On 8/5/2026 6:37 AM, Jason Gunthorpe wrote:
> > On Thu, Jul 30, 2026 at 04:56:37PM +0530, Vasant Hegde wrote:
> >
> >> Based on discussion so far in this thread and the link Mario shared earlier
> [1]:
> >>   - We still need identity mapping for APUs. I will fine tune the
> >> patch based on the discussion in this thread.
> >
> > IMHO if certain HW has broken support for PAGING (eg because it can't
> > handle the isochronous needs) then it should be quirked and blocked
> > properly.
> >
> > I thought the issue here was the PASID check forcing identity and
> > accidently capturing these raven chips too? It should just be moved
> > out to a normal quirk..
> >
> >>   - Its fine to drop SNP check
> >>   - I am still not sure its safe to drop SME check (CC_ATTR_MEM_ENCRYPT)
> >>     Because here were are putting all APUs in identity mode.
> >>     Commit ea68573d408f explicitly error out for RAVEN and some of
> >> the older APU platform didn't support SME. But not sure about newer
> ones.
> >
> > That's quite a hacky check to make in that commit..
> >
> >> So I am inclined to keep SME check for now. Once this patch
> >> stabilized we can revisit the SME check?
> >
> > The SME check makes no sense either, but if you want to stage things
> > I'm OK with it.
>
> Right. Eventually it should remove SME as well. But I am concerned about any
> regression. Also I don't have all these devices to test it. Hence for now I will
> limit to APUs, keep SME check and drop SNP check. Once it settle, we can go
> with next step.

IIRC, they supported SME, but it wasn't usable due to other limitations (e.g., the requirement for identity mappings due to the display hw bug and the latency impact of encryption for displays in system memory).  Do you could effectively pick either SME or displays.

Alex

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Jason Gunthorpe]

On Wed, Aug 05, 2026 at 05:22:22PM +0000, Deucher, Alexander wrote:

> IIRC, they supported SME, but it wasn't usable due to other
> limitations (e.g., the requirement for identity mappings due to the
> display hw bug and the latency impact of encryption for displays in
> system memory).  Do you could effectively pick either SME or
> displays.

IMHO the GPU driver should fail if it cannot work because it can't
reach the IOVA space requried for SME ...

I don't think this should be a iommu problem to deal with

Jason

RE: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Deucher, Alexander]

Public

> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Wednesday, August 5, 2026 1:53 PM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>
> Cc: Hegde, Vasant <Vasant.Hegde@amd.com>; Limonciello, Mario
> <Mario.Limonciello@amd.com>; Kuehling, Felix <Felix.Kuehling@amd.com>;
> iommu@lists.linux.dev; joro@8bytes.org; linux-pci@vger.kernel.org;
> will@kernel.org; robin.murphy@arm.com; Suthikulpanit, Suravee
> <Suravee.Suthikulpanit@amd.com>; bhelgaas@google.com; Longia,
> Amandeep Kaur <AmandeepKaur.Longia@amd.com>
> Subject: Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs
> only
>
> On Wed, Aug 05, 2026 at 05:22:22PM +0000, Deucher, Alexander wrote:
>
> > IIRC, they supported SME, but it wasn't usable due to other
> > limitations (e.g., the requirement for identity mappings due to the
> > display hw bug and the latency impact of encryption for displays in
> > system memory).  Do you could effectively pick either SME or displays.
>
> IMHO the GPU driver should fail if it cannot work because it can't reach the
> IOVA space requried for SME ...
>
> I don't think this should be a iommu problem to deal with

That means no display for the user which is a not a good user experience. Most users of systems with integrated graphics would probably prefer displays over SME.

Alex

Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Jason Gunthorpe]

On Wed, Aug 05, 2026 at 06:12:05PM +0000, Deucher, Alexander wrote:

> > On Wed, Aug 05, 2026 at 05:22:22PM +0000, Deucher, Alexander wrote:
> >
> > > IIRC, they supported SME, but it wasn't usable due to other
> > > limitations (e.g., the requirement for identity mappings due to the
> > > display hw bug and the latency impact of encryption for displays in
> > > system memory).  Do you could effectively pick either SME or displays.
> >
> > IMHO the GPU driver should fail if it cannot work because it can't reach the
> > IOVA space requried for SME ...
> >
> > I don't think this should be a iommu problem to deal with
> 
> That means no display for the user which is a not a good user
> experience. Most users of systems with integrated graphics would
> probably prefer displays over SME.

You said IOVA translation doesn't work at all on these devices due to
a bug, so what is the iommu even supposed to do? It can't select
identity because the device doesn't work that way and it can't select
paging because it doesn't work that way either.

Or are you saying paging sort of works enough to do something
half-busted?

Why did AMD even offer SME in the BIOS on these systems if it doesn't
even work and turn it into Linux's problem?

Jason

RE: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Deucher, Alexander]

Public

> -----Original Message-----
> From: Limonciello, Mario <Mario.Limonciello@amd.com>
> Sent: Tuesday, July 28, 2026 3:58 PM
> To: Kuehling, Felix <Felix.Kuehling@amd.com>; Hegde, Vasant
> <Vasant.Hegde@amd.com>; Jason Gunthorpe <jgg@ziepe.ca>; Deucher,
> Alexander <Alexander.Deucher@amd.com>
> Cc: iommu@lists.linux.dev; joro@8bytes.org; linux-pci@vger.kernel.org;
> will@kernel.org; robin.murphy@arm.com; Suthikulpanit, Suravee
> <Suravee.Suthikulpanit@amd.com>; bhelgaas@google.com; Longia,
> Amandeep Kaur <AmandeepKaur.Longia@amd.com>
> Subject: Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs
> only
>
>
>
> On 7/28/26 14:10, Kuehling, Felix wrote:
> > On 2026-07-28 01:31, Mario Limonciello wrote:
> >> +Felix
> >>
> >> On 7/27/26 23:52, Vasant Hegde wrote:
> >>> Mario,
> >>>
> >>>
> >>> On 7/27/2026 8:15 PM, Mario Limonciello wrote:
> >>>>
> >>>>
> >>>> On 7/26/26 23:19, Vasant Hegde wrote:
> >>>>>
> >>>>>
> >>>
> >>> .../...
> >>>
> >>>>>>
> >>>>>> I think this can probably be dropped now? There is no
> >>>>>> intersection of this old broken embedded GPU and a CPU that
> supports CC right?
> >>>>>
> >>>>>
> >>>>> I did consider dropping these two checks, but I was not entirely
> >>>>> sure. So I kept as is for now. Once these series settles and I can
> >>>>> go with next step of dropping these two checks.
> >>>>>
> >>>>> @Alex, @Mario, Any suggestions ?
> >>>>>
> >>>>
> >>>> The background comes from this series:
> >>>>
> >>>> https://lore.kernel.org/all/20200824105415.21000-1-
> joro@8bytes.org/
> >>>
> >>>
> >>> Thanks for old link. So it looks like we are good to drop SME check?
> >>
> >> Yeah I think so.
> >>
> >>>
> >>> Also is it safe to assume SNP is not enabled on these platform and
> >>> drop that check? Anyway SNP requirement (which doesn't support
> >>> identity
> >>> mapping) and APU
> >>> requirement (needs identity mapping) is conflicting.
> >>>
> >>
> >> The current platforms I think this is a safe assumption.
> >>
> >> Felix,
> >>
> >> Can we revisit the requirement of identity mapping for APU?  Does it
> >> still hold with the current hardware and software?
> >
> > I'm not sure what this means. Is Identity mode something like pass-
> > through? I don't know why this is required on APUs. If it's related to
> > IOMMUv2 support, then it's probably no longer needed. We're not using
> > IOMMUv2 on our APUs any more. Support for that was removed from the
> > amdgpu driver a few years ago.
> >
>
> Hmm, I just had a try with this on a few years old APU (PHX).  It's flicker central
> with this (7.2-rc5~ish tree):
>
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 29dc18d3d22e5..1e792cee7f4cd 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3134,19 +3134,6 @@ static int amd_iommu_def_domain_type(struct
> device *dev)
>          if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
>                  return IOMMU_DOMAIN_DMA;
>
> -       /*
> -        * Do not identity map IOMMUv2 capable devices when:
> -        *  - memory encryption is active, because some of those devices
> -        *    (AMD GPUs) don't have the encryption bit in their DMA-mask
> -        *    and require remapping.
> -        *  - SNP is enabled, because it prohibits DTE[Mode]=0.
> -        */
> -       if (pdev_pasid_supported(dev_data) &&
> -           !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
> -           !amd_iommu_snp_en) {
> -               return IOMMU_DOMAIN_IDENTITY;
> -       }
> -
>          return 0;
>   }
>
> The flicking is reminencent of issues moving BOs between VRAM and GTT
> from a few years ago.
>
> So I don't think it can be dropped (just) yet.

Make sure ATS is enabled.  Display buffers in system memory are really sensitive to latency.  Some of the older pre-raven chips like carrizo would flicker even with an identify mapping.

Alex

RE: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only

[Deucher, Alexander]

AMD General

> -----Original Message-----
> From: Limonciello, Mario <Mario.Limonciello@amd.com>
> Sent: Tuesday, July 28, 2026 1:31 AM
> To: Hegde, Vasant <Vasant.Hegde@amd.com>; Jason Gunthorpe
> <jgg@ziepe.ca>; Deucher, Alexander <Alexander.Deucher@amd.com>;
> Kuehling, Felix <Felix.Kuehling@amd.com>
> Cc: iommu@lists.linux.dev; joro@8bytes.org; linux-pci@vger.kernel.org;
> will@kernel.org; robin.murphy@arm.com; Suthikulpanit, Suravee
> <Suravee.Suthikulpanit@amd.com>; bhelgaas@google.com; Longia,
> Amandeep Kaur <AmandeepKaur.Longia@amd.com>
> Subject: Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs
> only
>
> +Felix
>
> On 7/27/26 23:52, Vasant Hegde wrote:
> > Mario,
> >
> >
> > On 7/27/2026 8:15 PM, Mario Limonciello wrote:
> >>
> >>
> >> On 7/26/26 23:19, Vasant Hegde wrote:
> >>>
> >>>
> >
> > .../...
> >
> >>>>
> >>>> I think this can probably be dropped now? There is no intersection
> >>>> of this old broken embedded GPU and a CPU that supports CC right?
> >>>
> >>>
> >>> I did consider dropping these two checks, but I was not entirely
> >>> sure. So I kept as is for now. Once these series settles and I can
> >>> go with next step of dropping these two checks.
> >>>
> >>> @Alex, @Mario, Any suggestions ?
> >>>
> >>
> >> The background comes from this series:
> >>
> >> https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/
> >
> >
> > Thanks for old link. So it looks like we are good to drop SME check?
>
> Yeah I think so.
>
> >
> > Also is it safe to assume SNP is not enabled on these platform and
> > drop that check? Anyway SNP requirement (which doesn't support
> > identity mapping) and APU requirement (needs identity mapping) is
> conflicting.
> >
>
> The current platforms I think this is a safe assumption.
>
> Felix,
>
> Can we revisit the requirement of identity mapping for APU?  Does it still hold
> with the current hardware and software?
>
> I'm wondering if we can just apply it to Raven and loosen up elsewhere and
> what gives if we do that.


This issue only applies to the early raven/picasso families.  The display hardware had some hardware addressing bug with IOVAs so it has to have IOVA = IOPA.  The rest of the GPU can handle IOVAs just fine. This was fixed on Renoir IIRC.

Alex