Re: [PATCH v2] iommu/amd: Enhance def_domain_type to handle untrusted device

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 24, 2024 at 01:41:57PM +0530, Vasant Hegde wrote:
> Hi Robin,
> 
> 
> On 4/23/2024 4:56 PM, Robin Murphy wrote:
> > On 23/04/2024 12:17 pm, Vasant Hegde wrote:
> >> Previously, IOMMU core layer was forcing IOMMU_DOMAIN_DMA domain for
> >> untrusted device. This always took precedence over driver's
> >> def_domain_type(). Commit 59ddce4418da ("iommu: Reorganize
> >> iommu_get_default_domain_type() to respect def_domain_type()") changed
> >> the behaviour. Current code calls def_domain_type() but if it doesn't
> >> return IOMMU_DOMAIN_DMA for untrusted device it throws error. This
> >> results in IOMMU group (and potentially IOMMU itself) in undetermined
> >> state.
> >>
> >> This patch adds untrusted check in AMD IOMMU driver code. So that it
> >> allows eGPUs behind Thunderbolt work again.
> > 
> > Sorry, but I firmly disagree with this approach - regardless of what the AMD
> > driver is currently doing and how appropriate it may or may not be, we should
> > not be duplicating core code policy in drivers, 

Then AMD should remove the PASID stuff from def_domain_type and we
need to fix it with properly designed core support for this limitation
before merging the SVA support.

> > and we certainly shouldn't be
> > doing so to bodge around a breakage in how the core code implements said policy.

It isn't breakage. It is evolution of the API.

Hacking in the AMD driver is temprary and Vasant will eventually fix
it. Regressing the core code to go back to allowing drivers to inform
policy is much harder to undo.

Jason