> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, June 16, 2021 7:41 AM > > On Tue, Jun 15, 2021 at 11:09:37PM +0000, Tian, Kevin wrote: > > > which information can you elaborate? This is the area which I'm not > > familiar with thus would appreciate if you can help explain how this > > bus specific information is utilized within the attach function or > > sometime later. > > This is the idea that the device driver needs to specify which bus > specific protocol it uses to issue DMA's when it attaches itself to an > IOASID. For PCI: What about defining some general attributes instead of asking iommu fd to understand those bus specific detail? > > - Normal RID DMA this is struct device pointer > - PASID DMA this is PASID or SSID which is understood by underlying iommu driver > - ENQCMD triggered PASID DMA from iommu p.o.v there is no difference from last one. In v2 the device driver just needs to communicate the PASID virtualization policy at device binding time, e.g. whether vPASID is allowed, if yes whether vPASID must be registered to the kernel, if via kernel whether per-RID vs. global, etc. This policy is then conveyed to userspace via device capability query interface via iommu fd. > - ATS/PRI enabled or not Just a generic support I/O page fault or not > > And maybe more. Eg CXL has some other operating modes, I think > > The device knows what it is going to do, we need to convey that to the > IOMMU layer so it is prepared properly. > Yes, but it's not necessarily to have iommu fd understand bus specific attributes. In the end when /dev/iommu uAPI calls iommu layer interface, it's all bus agnostic. Thanks Kevin
