> From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Thursday, June 22, 2023 5:54 AM > > On Fri, 16 Jun 2023 02:39:46 -0700 > Yi Liu <yi.l.liu@xxxxxxxxx> wrote: > > +VFIO device cdev doesn't rely on VFIO group/container/iommu drivers. > > +Hence those modules can be fully compiled out in an environment > > +where no legacy VFIO application exists. > > + > > +So far SPAPR does not support IOMMUFD yet. So it cannot support device > > +cdev either. > > Why isn´t this enforced via Kconfig? At the vfio level we could simply > add the following in patch 17/: > > config VFIO_DEVICE_CDEV > bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" > depends on IOMMUFD && !SPAPR_TCE_IOMMU > ^^^^^^^^^^^^^^^^^^^ > > Or if Jason wants, IOMMUFD could depend on !SPAPR_TCE_IOMMU for now and > the existing Kconfig options would exclude it. If we know it doesn't > work, let's not put the burden on the user to figure that out. A > follow-up patch for this would be fine if there's no other reason to > respin the series. @Jason, How about your opinion? Seems reasonable to make IOMMUFD depend on !SPAPR_TCE_IOMMU. Is it? > Otherwise the series is looking pretty good to me. It still requires > some reviews/acks in the iommufd space and it would be good to see more > reviews for the remainder given the amount of collaboration here. > > I'm out for the rest of the week, but I'll leave open accepting this > and the hot-reset series next week for the merge window. Thanks, @Alex, Given Jason's remarks on cdev v12, I've already got a new version as below. I can post it once the above kconfig open is closed. https://github.com/yiliu1765/iommufd/tree/wip/vfio_device_cdev_v14 Regards, Yi Liu
