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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
