Messages in this thread | | | Date | Thu, 25 Apr 2024 09:41:44 +0800 | Subject | Re: [PATCH] iommu: Fix def_domain_type interaction with untrusted devices | From | Baolu Lu <> |
| |
On 4/24/24 10:37 PM, Jason Gunthorpe wrote: > 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.
Yes. I will follow up to address this issue in the intel driver.
Best regards, baolu
| |