On Mon, May 09, 2022 at 11:06:35PM +0100, Robin Murphy wrote: > The main thing drivers need to do for flush queue support is to actually > implement the optimisations which make it worthwhile. It's up to individual > drivers how much use they want to make of the iommu_iotlb_gather mechanism, > and they're free to issue invalidations or even enforce their completion > directly within their unmap callback if they so wish. In such cases, > enabling a flush queue would do nothing but hurt performance and waste > memory.
It makes sense, but I think at this point it would be clearer to have a domain->ops flag saying if the domain benefits from deferred flush or not rather than overloading the type > > But then what happens? This driver has no detach_dev so after, say > > VFIO does stuff, how do we get back into whatever boot-time state NULL > > represents? > > Shhh... the main point of the arm-smmu legacy binding support is to do > whatever the handful of people still using ancient AMD Seattle boards with > original firmware need to do. Clearly they haven't been reassigning devices > straight back from VFIO to a kernel driver for the last 6-and-a-bit years > since that's been broken, so I'm now discounting it as a supported > legacy-binding-use-case. Don't give them ideas! ;) If everything is converted to use default domain what will this return? NULL can't be a valid default domain.. > > It feels like this really wants a 'IOMMU_DOMAIN_PLATFORM_DMA_OPS' set > > as the default_domain meaning that when that domain is assigned, the > > platform's DMA ops are handling the iommu? If I get it right.. > > Nah, we just need to actually finish introducing default domains. I'm OK to > tackle the remaining SoC IOMMU drivers once my bus ops work meanders into > the arch/arm iommu-dma conversion revival; it just needs people who > understand s390 and fsl-pamu well enough to at least (presumably) bodge up > enough IOMMU_DOMAIN_IDENTITY support to replicate their current "detached" Hum. Looking at s390 it is similar I think to smmu - when NULL they expect their platform dma_ops to work in arch/s390/pci/pci_dma.c which looks to me like a version of the normal iommu support through IOMMU_DOMAIN_DMA. The good conversion is probably to move s390 to use the normal dma API, the lame one is to use a 'IOMMU_DOMAIN_PLATFORM_DMA_OPS' and save it for another day. fsl took some looking at, but it looks very much like IDENTITY. The defconfig does not set CONFIG_DMA_OPS and there is no dma_ops code aroudn it's arch support - so it follow the direct path. It seems like there might be an offset though. The two tegras look OK, they both look like blocking domains. Theirry has been helpful at tegra stuff in pthe past. Someone who cared about fsl tested a VFIO patch of mine last year, and the s390 team is actively looking at nested domains right now. > behaviours and force CONFIG_IOMMU_DEFAULT_PASSTHROUGH on those > architectures. Or should the iommu driver return IDENTITY from its ops def_domain_type() ? Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
