On Wed, Jun 09, 2021 at 02:24:03PM +0200, Joerg Roedel wrote: > On Mon, Jun 07, 2021 at 02:58:18AM +0000, Tian, Kevin wrote: > > - Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully > > convinced yet. Based on discussion v2 will continue to have ioasid uAPI > > being device-centric (but it's fine for vfio to be group-centric). A new > > section will be added to elaborate this part; > > I would vote for group-centric here. Or do the reasons for which VFIO is > group-centric not apply to IOASID? If so, why? VFIO being group centric has made it very ugly/difficult to inject device driver specific knowledge into the scheme. The device driver is the only thing that knows to ask: - I need a SW table for this ioasid because I am like a mdev - I will issue TLPs with PASID - I need a IOASID linked to a PASID - I am a devices that uses ENQCMD and vPASID - etc in future The current approach has the group try to guess the device driver intention in the vfio type 1 code. I want to see this be clean and have the device driver directly tell the iommu layer what kind of DMA it plans to do, and thus how it needs the IOMMU and IOASID configured. This is the source of the ugly symbol_get and the very, very hacky 'if you are a mdev *and* a iommu then you must want a single PASID' stuff in type1. The group is causing all this mess because the group knows nothing about what the device drivers contained in the group actually want. Further being group centric eliminates the possibility of working in cases like !ACS. How do I use PASID functionality of a device behind a !ACS switch if the uAPI forces all IOASID's to be linked to a group, not a device? Device centric with an report that "all devices in the group must use the same IOASID" covers all the new functionality, keep the old, and has a better chance to keep going as a uAPI into the future. Jason
