[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