From: sashiko-bot@kernel.org
To: "Vasant Hegde" <vasant.hegde@amd.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] iommu/amd: Force identity mode for selected GPUs only
Date: Mon, 24 Aug 2026 09:09:01 +0000 [thread overview]
Message-ID: <20260824090901.752F91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260824085821.5422-1-vasant.hegde@amd.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Missing NULL pointer check for `pci_upstream_bridge()` causes a kernel panic during boot on systems where the GPU is on the root bus.
- [High] The heuristic used to distinguish discrete GPUs (dGPUs) from APU GPUs is flawed and will incorrectly force identity mapping on many dGPUs.
- [High] Discrete GPUs break on SNP-enabled systems due to the removal of the SNP check combined with flawed GPU identification.
--
--- Patch [1]: [PATCH v2] iommu/amd: Force identity mode for selected GPUs only ---
commit 8994b69ea108b9e83363d3bf65d86e8798e45ba5
Author: Vasant Hegde <vasant.hegde@amd.com>
iommu/amd: Force identity mode for selected GPUs only
This commit updates AMD IOMMU domain allocation to force identity mapping
only for specific APU GPUs, rather than all PASID-capable devices. It
introduces quirks_force_identity_mapping() to apply this targeted enforcement
and drops the previous SNP check.
Link: https://lore.kernel.org/all/20200824105415.21000-1-joro@8bytes.org/
Link: https://lore.kernel.org/linux-iommu/20260723061548.10187-1-vasant.hegde@amd.com/
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 4dc306a4b5c62..eef585918e607 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3165,6 +3165,26 @@ 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)
> +{
> + 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)->vendor == PCI_VENDOR_ID_ATI)
[Severity: Critical]
Is it possible for pci_upstream_bridge() to return NULL here?
If the GPU is located on the PCIe root bus (such as in an integrated SoC
design, or when passed through to a VM via VFIO), pci_upstream_bridge(pdev)
would return NULL. This would lead to a kernel panic when dereferencing
->vendor during boot.
> + return false;
> +
> + /* It is the GPU in an APU, force identity domain */
> + return true;
> +}
[Severity: High]
Does this heuristic accurately distinguish APUs from standard discrete GPUs?
Standard discrete GPUs are typically plugged directly into motherboard PCIe
slots, which means their upstream bridge is the motherboard's root port
(e.g., an Intel or AMD root port, not an ATI switch). Since the root port
vendor is not ATI, this check would fall through and erroneously return true,
forcing standard discrete GPUs into the identity domain.
[ ... ]
> - /*
> - * 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;
> +
> + return IOMMU_DOMAIN_IDENTITY;
> }
[Severity: High]
Since the amd_iommu_snp_en check was dropped, how does this affect discrete
GPUs on SNP-enabled systems?
If standard discrete GPUs are incorrectly identified as APUs by
quirks_force_identity_mapping(), they will be unconditionally forced into
IOMMU_DOMAIN_IDENTITY here when SME is disabled.
On systems with SNP enabled, amd_iommu_identity_attach() will reject the
identity domain if Mode0 isn't supported, returning -EINVAL. Could this leave
the discrete GPU without a valid domain and break DMA entirely?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260824085821.5422-1-vasant.hegde@amd.com?part=1
next prev parent reply other threads:[~2026-08-24 9:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 8:58 [PATCH v2] iommu/amd: Force identity mode for selected GPUs only Vasant Hegde
2026-08-24 9:09 ` sashiko-bot [this message]
2026-08-24 13:18 ` Mario Limonciello
2026-08-24 13:24 ` Jason Gunthorpe
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=20260824090901.752F91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vasant.hegde@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox