Messages in this thread | | | Date | Fri, 24 Jun 2022 11:56:27 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v2 1/2] vfio/type1: Simplify bus_type determination |
| |
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
| |