From: Jason Gunthorpe <jgg@nvidia.com>
Sent: Friday, July 30, 2021 10:51 PM

On Mon, Jul 26, 2021 at 02:50:48PM +1000, David Gibson wrote:

quoted

That said, I'm still finding the various ways a device can attach to
an ioasid pretty confusing.  Here are some thoughts on some extra
concepts that might make it easier to handle [note, I haven't thought
this all the way through so far, so there might be fatal problems with
this approach].

I think you've summarized how I've been viewing this problem. All the
concepts you pointed to should show through in the various APIs at the
end, one way or another.

I still didn't get the value of making endpoint explicit in /dev/iommu uAPI. 
From IOMMU p.o.v it only cares how to route incoming DMA traffic to a
specific I/O page table, according to RID or RID+PASID info carried in DMA 
packets. This has been covered by this proposal. Which DMA endpoint in 
the source device actually triggers the traffic is not a matter for /dev/iommu...

How much we need to expose to userspace, I don't know.

Does userspace need to care how the system labels traffic between DMA
endpoint and the IOASID? At some point maybe yes since stuff like
PASID does leak out in various spots

Can you elaborate? IMO the user only cares about the label (device cookie 
plus optional vPASID) which is generated by itself when doing the attaching
call, and expects this virtual label being used in various spots (invalidation,
page fault, etc.). How the system labels the traffic (the physical RID or RID+
PASID) should be completely invisible to userspace.

Thanks
Kevin