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

"Deucher, Alexander" <[email protected]> Fri, 31 Jul 2026 20:23:14 +0000
Newsgroups org.kernel.vger.linux-pci,dev.linux.lists.iommu
Message-ID <BN9PR12MB51464567463FE49B084AD57CF7C82@BN9PR12MB5146.namprd12.prod.outlook.com>
Public

> -----Original Message-----
> From: Limonciello, Mario <[email protected]>
> Sent: Tuesday, July 28, 2026 3:58 PM
> To: Kuehling, Felix <[email protected]>; Hegde, Vasant
> <[email protected]>; Jason Gunthorpe <[email protected]>; Deucher,
> Alexander <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Suthikulpanit, Suravee
> <[email protected]>; [email protected]; Longia,
> Amandeep Kaur <[email protected]>
> 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-
> [email protected]/
> >>>
> >>>
> >>> 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