On Fri, Jun 24, 2022 at 08:28:31AM -0600, Alex Williamson wrote: > > > That's essentially what I'm suggesting, the vfio_group is passed as an > > > opaque pointer which type1 can use for a > > > vfio_group_for_each_vfio_device() type call. Thanks, > > > > I don't want to add a whole vfio_group_for_each_vfio_device() > > machinery that isn't actually needed by anything.. This is all > > internal, we don't need to design more than exactly what is needed. > > > > At this point if we change the signature of the attach then we may as > > well just pass in the representative vfio_device, that is probably > > less LOC overall. > > That means that vfio core still needs to pick an arbitrary > representative device, which I find in fundamental conflict to the > nature of groups. Well, this is where iommu is going, I think Robin has explained this view well enough. Ideally we'd move VFIO away from trying to attach groups and attach when the device FD is opened, I view this as a micro step in that direction. > Type1 is the interface to the IOMMU API, if through the IOMMU API we > can make an assumption that all devices within the group are > equivalent for a given operation, that should be done in type1 code, > not in vfio core. iommu_group is part of the core code, if the representative device assumption stems from the iommu_group then the core code can safely make it. > A for-each interface is commonplace and not significantly more code > or design than already proposed. Except that someone else might get the idea to use it for something completely inappropriate. Jason
