On Mon, Sep 18, 2023, Jason Gunthorpe wrote: > On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote: > > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to > > VFIO instead of having VFIO do a symbol lookup back into KVM. Having both > > KVM and VFIO do symbol lookups increases the overall complexity and places > > an unnecessary dependency on KVM (from VFIO) without adding any value. > > > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> > > --- > > drivers/vfio/vfio.h | 2 ++ > > drivers/vfio/vfio_main.c | 74 +++++++++++++++++++--------------------- > > include/linux/vfio.h | 4 ++- > > virt/kvm/vfio.c | 9 +++-- > > 4 files changed, 47 insertions(+), 42 deletions(-) > > I don't mind this, but Christoph had disliked my prior attempt to do > this with function pointers.. > > The get can be inlined, IIRC, what about putting a pointer to the put > inside the kvm struct? That wouldn't allow us to achieve our goal, which is to hide the details of "struct kvm" from VFIO (and the rest of the kernel). What's the objection to handing VFIO a function pointer? > The the normal kvm get/put don't have to exported symbols at all? The export of kvm_get_kvm_safe() can go away (I forgot to do that in this series), but kvm_get_kvm() will hang around as it's needed by KVM sub-modules (PPC and x86), KVMGT (x86), and drivers/s390/crypto/vfio_ap_ops.c (no idea what to call that beast). Gah, KVMGT doesn't actually need to call get/put, that can be handled by kvm_page_track_register_notifier(). I am planning on making exports for sub-modules conditional on there actually being submodules, so that's 2 of the 3 gone, but tackling the s390 crypto driver is an entirely different story.
