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

From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Eric Auger <eric.auger@redhat.com>,
	Christoph Hellwig <hch@lst.de>, Yi Liu <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 06:45:34 +0200	[thread overview]
Message-ID: <20220415044533.GA22209@lst.de> (raw)
In-Reply-To: <4-v1-33906a626da1+16b0-vfio_kvm_no_group_jgg@nvidia.com>

On Thu, Apr 14, 2022 at 03:46:03PM -0300, Jason Gunthorpe wrote:
> 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.
> 
> Following patches will redo each of the symbol_get() calls into an
> indirection through this ops struct.

So I got anoyed at this as well a while ago and I still think this
is the wrong way around.

I'd much rather EXPORT_SYMBOL_GPL kvm_register_device_ops and
just let kvm_vfio_ops live in a module than all the symbol_get
crazyness.  We'll need to be careful to deal with unload races
or just not allow unloading, though.