Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: 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, mario.limonciello@amd.com,
	felix.kuehling@amd.com
Subject: Re: [PATCH v2] iommu/amd: Force identity mode for selected GPUs only
Date: Mon, 24 Aug 2026 10:24:09 -0300	[thread overview]
Message-ID: <20260824132409.GC1449020@ziepe.ca> (raw)
In-Reply-To: <20260824085821.5422-1-vasant.hegde@amd.com>

On Mon, Aug 24, 2026 at 08:58:21AM +0000, Vasant Hegde wrote:
> Certain AMD GPUs must always operate in IOMMU identity mode. This was
> previously enforced using a PASID check, which happened to work because
> these specific GPUs are PASID-capable. However, this approach incorrectly
> applies identity mode enforcement to all PASID-capable devices, not just
> the GPUs that require it.
> 
> This made sense in the past because the domain allocation API
> (iommu_ops->domain_alloc()) only received the domain type, so the
> driver had no way to inspect device capabilities and pick the most
> suitable page table format (v1 or v2). With the recent driver
> enhancement to use domain_alloc_paging_flags() for all paging
> domain allocations, the driver can now inspect the device and flags
> directly and choose the appropriate page table type per device.
> 
> Update amd_iommu_def_domain_type() to force identity mapping only for
> the specific GPUs that require it, via a new quirks_force_identity_mapping().
> 
> With this change, a system booting in DMA translation mode will now
> select:
>  * Guest (v2) page table for PASID-capable devices
>  * Host (v1) page table for non-PASID-capable devices
> 
> Also drop the amd_iommu_snp_en check, as SNP enforces paging domain,
> which doesn't work with the identity requirement of these GPUs.
> 
> 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/
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
> Changes in v2:
>   - Dropped disabling ATS for "Radeon Pro WX 4100"
>   - Addressed review comments
> 
> @Jason,
>   Once this patch settles, I will send separate patch to drop
>   'untrusted' check inside amd_iommu_def_domain_type().
> 
>   Regarding SME check, I have retained SME chek inside
>   quirks_force_identity_mapping(). If everyone is fine to drop then I
>   will do follow up patch later.

Sure

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

> +	/* 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 still haven't seen an explanation why this make sense. This
patch says two conflicting things:

1) We need identity for the APU cases because they can't handle
   translation
2) We can't have identity for the SME case because it can't handle the
   high address bit, so use paging.

Surely #2 is also a per-GPU version thing and this address width issue
was fixed in newer chips?

But even so, if paging doesn't work why is it OK to use it for SME? If
paging does work then why do we quirk it away?

Jason


      parent reply	other threads:[~2026-08-24 13:24 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
2026-08-24 13:18 ` Mario Limonciello
2026-08-24 13:24 ` Jason Gunthorpe [this message]

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=20260824132409.GC1449020@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=alexander.deucher@amd.com \
    --cc=bhelgaas@google.com \
    --cc=felix.kuehling@amd.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox