Re: [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 15, 2022 at 03:57:14AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Friday, April 15, 2022 2:46 AM
> > 
> > kvm and VFIO need to be coupled together however neither is willing to
> > tolerate a direct module dependency. Instead when kvm is given a VFIO FD
> > it uses many symbol_get()'s to access VFIO.
> > 
> > Provide a single VFIO function vfio_file_get_ops() which validates the
> > given struct file * is a VFIO file and then returns a struct of ops.
> 
> VFIO has multiple files (container, group, and device). Here and other
> places seems to assume a VFIO file is just a group file. While it is correct
> in this external facing context, probably calling it 'VFIO group file' is
> clearer in various code comments and patch descriptions.
> 
> > 
> > Following patches will redo each of the symbol_get() calls into an
> > indirection through this ops struct.
> > 
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> 
> 
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> 
> Out of curiosity, how do you envision when iommufd is introduced?
> Will we need a generic ops abstraction so both vfio and iommufd
> register their own ops to keep kvm side generic or a new protocol
> will be introduced between iommufd and kvm? 

I imagine using the vfio_device in all these context where the vfio
group is used, not iommufd. This keeps everything internal to vfio.

Jason