On Wed, Jun 09, 2021 at 03:32:34PM +0200, Joerg Roedel wrote: > > The group is causing all this mess because the group knows nothing > > about what the device drivers contained in the group actually want. > > There are devices in the group, not drivers. Well exactly, that is the whole problem. Only *drivers* know what the actual device is going to do, devices do not. Since the group doesn't have drivers it is the wrong layer to be making choices about how to configure the IOMMU. As I've said trying to cram these necessary choices through the group has made mess. I think if people want to keep the group then they need to come up with a reasonable in-kernel API that gets the driver involved in the required decisions. ie figure out how to do PASID support on VFIO type1 that isn't grotequesly hardwired to mdev like today. The device centric approach is my attempt at this, and it is pretty clean, I think. > > 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? > > You don't use it, because it is not secure for devices which are not > behind an ACS bridge. All ACS does is prevent P2P operations, if you assign all the group devices into the same /dev/iommu then you may not care about that security isolation property. At the very least it is policy for user to decide, not kernel. > > 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. > > If all devices in the group have to use the same IOASID anyway, That isn't true! That is true *today* due to the API design but nothing about the HW forces this, and with PASID it starts to become problematic. Groups should be primarily about isolation security, not about IOASID matching. Again, there is no reason to block PASID support in the vIOMMU if all the devices in the group are assigned into the same VM, and the HW can properly match the (RID,PASID). PASID can't transit a PCI-PCIe bridge, PASID isn't supported by old IOMMUs that can't do RID matching, so PASID scenarios should always be able to determine the source regardless of what the group layout is. Blocking this forever in the new uAPI just because group = IOASID is some historical convenience makes no sense to me. Jason
