On Wed, Mar 10, 2021 at 09:15:08AM +0100, Christoph Hellwig wrote: > > + vfio_pci_vf_token_user_add(vdev, -1); > > + vfio_pci_core_spapr_eeh_release(vdev); > > + vfio_pci_core_disable(vdev); > > + } > > + mutex_unlock(&vdev->reflck->lock); > > But more importantly all this code should be in a helper exported > from the core code. Yes, that needs more refactoring. I'm viewing this series as a "statement of intent" and once we commit to doing this we can go through the bigger effort to split up vfio_pci_core and tidy its API. Obviously this is a big project, given the past comments I don't want to send more effort here until we see a community consensus emerge that this is what we want to do. If we build a sub-driver instead the work is all in the trash bin. > > + module_put(THIS_MODULE); > > This looks bogus - the module reference is now gone while > igd_vfio_pci_release is still running. Module refcounting always > need to be done by the caller, not the individual driver. Yes, this module handling in vfio should be in the core code linked to the core fops driven by the vfio_driver_ops. It is on my list to add to my other series, this isn't the only place in VFIO drivers are doing this.. > > + case PCI_VENDOR_ID_INTEL: > > + if (pdev->class == PCI_CLASS_DISPLAY_VGA << 8) > > + return get_igd_vfio_pci_driver(pdev); > > And this now means that the core code has a dependency on the igd > one, making the whole split rather pointless. Yes, if CONFIG_VFIO_PCI_DRIVER_COMPAT is set - this is a uAPI so we don't want to see it broken. The intention is to organize the software layers differently, not to decouple the two modules. Future things, like the mlx5 driver that is coming, will not use this COMPAT path at all. Jason
