Re: [PATCH 1/5] iommu: Replace uses of IOMMU_CAP_CACHE_COHERENCY with dev_is_dma_coherent()

Robin Murphy
2022-04-06T17:37:59Z

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]