Re: [RFC PATCH v3 10/10] iommu/sva: Add support for private PASIDs

[Jordan Crouse <jcrouse@codeaurora.org>]

On Wed, Oct 17, 2018 at 03:21:43PM +0100, Jean-Philippe Brucker wrote:
> Hi Jordan,
> 
> On 12/10/2018 15:32, Jordan Crouse wrote:
> > On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
> >> Provide an API for allocating PASIDs and populating them manually. To ease
> >> cleanup and factor allocation code, reuse the io_mm structure for private
> >> PASID. Private io_mm has a NULL mm_struct pointer, and cannot be bound to
> >> multiple devices. The mm_alloc() IOMMU op must now check if the mm
> >> argument is NULL, in which case it should allocate io_pgtables instead of
> >> binding to an mm.
> >>
> >> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> >> ---
> >> Sadly this probably won't be the final thing. The API in this patch is
> >> used like this:
> >>
> >>         iommu_sva_alloc_pasid(dev, &io_mm) -> PASID
> >>         iommu_sva_map(io_mm, ...)
> >>         iommu_sva_unmap(io_mm, ...)
> >>         iommu_sva_free_pasid(dev, io_mm)
> >>
> >> The proposed API for auxiliary domains is in an early stage but might
> >> replace this patch and could be used like this:
> >>
> >>         iommu_enable_aux_domain(dev)
> >>         d = iommu_domain_alloc()
> >>         iommu_attach_aux(dev, d)
> >>         iommu_aux_id(d) -> PASID
> >>         iommu_map(d, ...)
> >>         iommu_unmap(d, ...)
> >>         iommu_detach_aux(dev, d)
> >>         iommu_domain_free(d)
> >>
> >> The advantage being that the driver doesn't have to use a special
> >> version of map/unmap/etc.
> >
> > Hi Jean-Phillippe -
> >
> > Have you thought about this any more? I want to send out a
> > refresh for the per-context pagetables for arm-smmu so if we want to change
> > the underlying assumptions this would be a great time.
> >
> > For my part I'm okay with either model. In fact the second one is closer
> > to the original implementation that I sent out so I have a clear development
> > path in mind for either option depending on what the community decides.
> 
> We'll probably go with the second model. I'm trying to make the latest
> version work with SMMUv3
> (https://lwn.net/ml/linux-kernel/20181012051632.26064-1-baolu.lu@linux.intel.com/)
> and I'd like to send an RFC soon

Okay. When you do, I'll try to add the v2 code and make it work with the Adreno
GPU.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project