On 17/10/2018 15:21, 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 <[email protected]> >>> Signed-off-by: Jean-Philippe Brucker <[email protected]> >>> --- >>> 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/[email protected]/) > and I'd like to send an RFC soon > > Thanks, > Jean > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.
Ugh. Please disregard this notice. Thanks, Jean _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
