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

From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Eric Auger <eric.auger@redhat.com>,
	Christoph Hellwig <hch@lst.de>, "Liu, Yi L" <yi.l.liu@intel.com>
Subject: RE: [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s
Date: Fri, 15 Apr 2022 03:57:14 +0000	[thread overview]
Message-ID: <BN9PR11MB52764D80F73203162C8E82268CEE9@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4-v1-33906a626da1+16b0-vfio_kvm_no_group_jgg@nvidia.com>

> 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? 