On Thu, Jun 20, 2024 at 04:19:46PM +0530, Vasant Hegde wrote:
But I have a feeling if we do that it should be done by re-attachingGot it. Thanks.Not exactly to individual device drivers, but it should be out of the[Unrelated to this patch]seems that for all domain attaches above is coded in a wrong orderYes, exactly. But simply changing the order isn't future-proof,
as ats is enabled after the cache tag is assigned.
considering ATS control will eventually be moved out of iommu drivers.
You mean ATS setup will be moved to individual device driver? Is there any
reason for that?
iommu drivers.
https://lore.kernel.org/linux-iommu/BL1PR12MB51441FC4303BD0442EDB7A9CF7FFA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
I remember of this discussion. May be we can provide API from IOMMU driver so
that individual driver can enable/disable ATS (like iommu_dev_enable_feature()).
the domain.
For instance if you look at how I structued SMMUv3, the ATSness is an
effective property of the domain type and ATS switches on and off
dynamically already.
Having an additional input to domain attach "inhibit ats", as a flag
would be all the support the driver would need to provide for the core
code to manage this with some kind of global policy.
I would suggest to steer VTD in that direction too and make the ATS
enable be done on domain attach, and put the first ATS enable in
attach, not in probe. The logic in smmuv3 would apply just as well to
VTD, though you'd need the hitless update logic too 🙂