RE: [RFC v2] /dev/iommu uAPI proposal

[Tian, Kevin]

> 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