Robin Murphy
2022-Apr-06 15:48 UTC
[PATCH 1/5] iommu: Replace uses of IOMMU_CAP_CACHE_COHERENCY with dev_is_dma_coherent()
On 2022-04-06 15:14, Jason Gunthorpe wrote:> On Wed, Apr 06, 2022 at 03:51:50PM +0200, Christoph Hellwig wrote: >> On Wed, Apr 06, 2022 at 09:07:30AM -0300, Jason Gunthorpe wrote: >>> Didn't see it >>> >>> I'll move dev_is_dma_coherent to device.h along with >>> device_iommu_mapped() and others then >> >> No. It it is internal for a reason. It also doesn't actually work >> outside of the dma core. E.g. for non-swiotlb ARM configs it will >> not actually work. > > Really? It is the only condition that dma_info_to_prot() tests to > decide of IOMMU_CACHE is used or not, so you are saying that there is > a condition where a device can be attached to an iommu_domain and > dev_is_dma_coherent() returns the wrong information? How does > dma-iommu.c safely use it then?The common iommu-dma layer happens to be part of the subset of the DMA core which *does* play the dev->dma_coherent game. 32-bit Arm has its own IOMMU DMA ops which do not. I don't know if the set of PowerPCs with CONFIG_NOT_COHERENT_CACHE intersects the set of PowerPCs that can do VFIO, but that would be another example if so.> In any case I still need to do something about the places checking > IOMMU_CAP_CACHE_COHERENCY and thinking that means IOMMU_CACHE > works. Any idea?Can we improve the IOMMU drivers such that that *can* be the case (within a reasonable margin of error)? That's kind of where I was hoping to head with device_iommu_capable(), e.g. [1]. Robin. [1] https://gitlab.arm.com/linux-arm/linux-rm/-/commit/53390e9505b3791adedc0974e251e5c7360e402e