On Thu, May 04, 2023 at 02:35:35PM +0200, Niklas Schnelle wrote: > On Wed, 2023-05-03 at 16:35 -0300, Jason Gunthorpe wrote: > > On Wed, May 03, 2023 at 06:17:58PM +0100, Robin Murphy wrote: > > > On 2023-05-01 19:03, Jason Gunthorpe wrote: > > > > > ---8<--- > > > > > > @@ -1940,7 +1944,11 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, > > > > if (type == IOMMU_DOMAIN_IDENTITY && bus->iommu_ops->identity_domain) > > > > return bus->iommu_ops->identity_domain; > > > > - domain = bus->iommu_ops->domain_alloc(type); > > > > + if ((type == IOMMU_DOMAIN_UNMANAGED || type == IOMMU_DOMAIN_DMA) && > > > > > > Logically, "type & __IOMMU_DOMAIN_PAGING", otherwise we're already missing > > > IOMMU_DOMAIN_DMA_FQ. Except maybe that's deliberate? > > > > It is deliberate for now, if it included FQ it would cause a bunch of > > ARM64 drivers to switch to lazy mode. I'll add a comment. > > > > I have drafted a followup series that removes all the > > DMA/DMA_FQ/UNMANAGED checks from the remaining 6 drivers. I did this > > by adding an op flag 'prefer to use FQ' and made the core code drive > > the FQ decision from ops. > > Ah that sounds like it could fit very well with s390's need for an even > lazier flush mode to handle the virtualized IOMMU with slow IOTLB flush > case aka _SQ / single flush queue mode. When you have anything ready > give me a ping and I can rework my DMA conversion on top of this. I'd like to get your S390 dma-api conversion merged ASAP! I have this general objective to get the modern architectures onto dma-iommu.c because I want to add new things to the dma-api :\ I had imagined a new op flag because it is is pretty simple, but a op->get_performance or something that reports some data that could help dma-iommu.c decide if lazy mode is worthwhile and if there is other tuning sounds interesting too.. Jason
