> From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> > Sent: Friday, August 6, 2021 12:45 PM > > > > In concept I feel the purpose of DMA endpoint is equivalent to the > routing > > > > info in this proposal. > > > > > > Maybe? I'm afraid I never quite managed to understand the role of the > > > routing info in your proposal. > > > > > > > the IOMMU routes incoming DMA packets to a specific I/O page table, > > according to RID or RID+PASID carried in the packet. RID or RID+PASID > > is the routing information (represented by device cookie +PASID in > > proposed uAPI) and what the iommu driver really cares when activating > > the I/O page table in the iommu. > > Ok, so yes, endpoint is roughly equivalent to that. But my point is > that the IOMMU layer really only cares about that (device+routing) > combination, not other aspects of what the device is. So that's the > concept we should give a name and put front and center in the API. > This is how this proposal works, centered around the routing info. the uAPI doesn't care what the device is. It just requires the user to specify the user view of routing info (device fd + optional pasid) to tag an IOAS. the user view is then converted to the kernel view of routing (rid or rid+pasid) by vfio driver and then passed to iommu fd in the attaching operation. and GET_INFO interface is provided for the user to check whether a device supports multiple IOASes and whether pasid space is delegated to the user. We just need a better name if pasid is considered too pci specific... But creating an endpoint per ioasid and making it centered in uAPI is not what the IOMMU layer cares about. Thanks Kevin
