Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

["joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org" <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>]

Hi Jean-Philippe,

On Wed, Nov 21, 2018 at 07:05:13PM +0000, Jean-Philippe Brucker wrote:
> For the moment though, I think we should allow device drivers to use the
> DMA-API at the same time as SVA.

Yeah, that makes sense.

> If a device driver has to map a management ring buffer for example,
> it's much nicer to use dma_alloc as usual rather than have them write
> their own DMA allocation routines.  Which is another reason to
> implement 2) above: the DMA-API would still act on the default_domain,
> and attaching an "extended" domain augments it with SVA features.
> Detaching from the device doesn't require copying mappings back to the
> default domain. Does that sound OK?

Yes, as I just wrote to Kevin, this sounds good.

> 	struct io_mm *io_mm;
> 	struct iommu_domain *domain;
> 
> 	domain = iommu_alloc_ext_domain(bus);
> 
> 	/* Set an mm-exit callback to disable PASIDs. More attributes
> 	   could be added later to change the capabilities of the ext
> 	   domain */
> 	iommu_domain_set_attr(domain, DOMAIN_ATTR_MM_EXIT_CB, &mm_exit);
> 
> 	/* Fails if the device doesn't support this domain type */
> 	iommu_attach_device(domain, dev);
> 
> 	/* Same as SVA v3, except a domain instead of dev as argument */
> 	io_mm = iommu_sva_bind_mm(domain, current->mm, ...);
> 
> 	/* on success, install the PASID in the device */
> 	pasid = io_mm->pasid;
> 
> 	/* Do more work */
> 
> 	iommu_sva_unbind_mm(io_mm);
> 	iommu_detach_device(domain, dev);

Okay, we can still discuss the naming and a few details, but that goes
into the right directions. One open questions is, for example, where the
pasid-allocator comes into play. As it looks the amdgpu driver needs it
even without an iommu enabled.


Regards,

	Joerg