From: Mario Limonciello <mario.limonciello@amd.com>
To: Bjorn Helgaas <helgaas@kernel.org>, Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
linux-pci@vger.kernel.org, will@kernel.org, robin.murphy@arm.com,
suravee.suthikulpanit@amd.com, bhelgaas@google.com,
alexander.deucher@amd.com, jgg@ziepe.ca,
Amandeep Kaur Longia <AmandeepKaur.Longia@amd.com>
Subject: Re: [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only
Date: Thu, 23 Jul 2026 11:11:47 -0500 [thread overview]
Message-ID: <f2242b3c-5d2e-41cf-9136-72a90e86d17b@amd.com> (raw)
In-Reply-To: <20260723155912.GB836122@bhelgaas>
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
>>
next prev parent reply other threads:[~2026-07-23 16:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 6:15 [PATCH 0/2] iommu/amd: Fix default domain selection for PASID-capable devices Vasant Hegde
2026-07-23 6:15 ` [PATCH 1/2] PCI: Mark Radeon Pro WX 4100 ATS as broken Vasant Hegde
2026-07-23 6:21 ` sashiko-bot
2026-07-23 15:42 ` Bjorn Helgaas
2026-07-23 15:45 ` Mario Limonciello
2026-07-23 16:51 ` Vasant Hegde
2026-07-23 6:15 ` [PATCH 2/2] iommu/amd: Force identity mode for selected GPUs only Vasant Hegde
2026-07-23 6:25 ` sashiko-bot
2026-07-23 15:53 ` Ankit Soni
2026-07-23 16:29 ` Vasant Hegde
2026-07-23 15:59 ` Bjorn Helgaas
2026-07-23 16:11 ` Mario Limonciello [this message]
2026-07-23 16:23 ` Vasant Hegde
2026-07-23 16:32 ` Mario Limonciello
2026-07-23 16:55 ` Vasant Hegde
2026-07-23 19:53 ` Bjorn Helgaas
2026-07-23 19:58 ` Mario Limonciello
2026-07-23 21:02 ` Bjorn Helgaas
2026-07-23 16:33 ` Vasant Hegde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2242b3c-5d2e-41cf-9136-72a90e86d17b@amd.com \
--to=mario.limonciello@amd.com \
--cc=AmandeepKaur.Longia@amd.com \
--cc=alexander.deucher@amd.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=linux-pci@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.