[Intel-gfx] [PATCH v13 22/22] docs: vfio: Add vfio device cdev description

Liu, Yi L yi.l.liu at intel.com
Tue Jun 27 08:54:33 UTC 2023


> From: Alex Williamson <alex.williamson at redhat.com>
> Sent: Thursday, June 22, 2023 5:54 AM
> 
> On Fri, 16 Jun 2023 02:39:46 -0700
> Yi Liu <yi.l.liu at intel.com> 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



More information about the Intel-gfx mailing list