RE: [RFC v2] /dev/iommu uAPI proposal
From: Tian, Kevin
Date: Mon Aug 09 2021 - 04:34:12 EST
> 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
> > > > 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.