Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 24 Apr 2024 11:37:02 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH] iommu: Fix def_domain_type interaction with untrusted devices |
| |
On Wed, Apr 24, 2024 at 10:18:00PM +0800, Baolu Lu wrote:
> For example, the intel iommu driver allows users to opt-in graphic in > passthrough mode, in that case def_domain_type will return > IOMMU_DOMAIN_IDENTITY no matter the device is trusted or not. > > if ((iommu_identity_mapping & IDENTMAP_GFX) && IS_GFX_DEVICE(pdev)) > return IOMMU_DOMAIN_IDENTITY; > > this potentially creates same conflict as the amd driver.
These performance policy choices should be done in the core code and they should interact correctly with other policy knobs like untrusted.
If Intel Graphics has some performance reason to prefer IDENTITY then it should work the same no matter the IOMMU it is connected to. I think just because the GPU is co-packaged with the IOMMU isn't a good reason to organize the software like this.
If having a policy of a performance boost to some devices is legitimate then I guess we'd need more levels on the command line: fast all IDENTITY fast-secure all DMA expect IDENTIY for special devices mostly-secure all DMA but unmapping is not strict secure all DMA and strict unmapping
How exactly you decide when the performance reason justfies IDENTITY, I don't know.. Would mlx5 800G NICs that can overwhelm most IOMMUs also go in that bucket too?
But yes, I'm quite adament that drivers should not be using def_domain_type as some kind of performance policy thing.
Jason
| ![\](/images/icornerr.gif) |