> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Friday, March 10, 2023 10:04 PM
>
> On Fri, Mar 10, 2023 at 02:15:32AM +0000, Tian, Kevin wrote:
> > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> > > Sent: Wednesday, March 8, 2023 9:14 PM
> > >
> > > After making the no-DMA drivers (samples/vfio-mdev) providing
> iommufd
> > > callbacks, __vfio_register_dev() should check the presence of the
> iommufd
> > > callbacks if CONFIG_IOMMUFD is enabled.
> > >
> > > Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx>
> > > ---
> > > drivers/vfio/vfio_main.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > > index 43bd6b76e2b6..89497c933490 100644
> > > --- a/drivers/vfio/vfio_main.c
> > > +++ b/drivers/vfio/vfio_main.c
> > > @@ -255,8 +255,9 @@ static int __vfio_register_dev(struct vfio_device
> > > *device,
> > > {
> > > int ret;
> > >
> > > - if (WARN_ON(device->ops->bind_iommufd &&
> > > - (!device->ops->unbind_iommufd ||
> > > + if (WARN_ON(IS_ENABLED(CONFIG_IOMMUFD) &&
> > > + (!device->ops->bind_iommufd ||
> > > + !device->ops->unbind_iommufd ||
> > > !device->ops->attach_ioas)))
> > > return -EINVAL;
> > >
> >
> > I don't think IS_ENABLED() check is necessary. those ops are
> > defined in the driver side w/o a conditional CONFIG_IOMMUFD.
> >
> > We should warn out lacking of those ops to the driver developer
> > as early as possible, instead of postponing it until someone
> > starts to build kernel with CONFIG_IOMMUFD.
>
> The ops are NULL if !CONFIG_IOMMUFD. The previous code was OK
> because
> it checked for non-null bind before demanding the others be non-null.
Now we want the no-dma drivers to reuse the emulated iommu op set,
so if CONFIG_IOMMUFD==y, bind_iommufd/unbind_iommufd/attach_ioas
should be non-null for all the drivers registered to vfio. Is it?
Regards,
Yi Liu
