> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Friday, August 27, 2021 6:59 AM
>
> On Thu, 26 Aug 2021 15:34:17 +0200
> Christoph Hellwig <hch@xxxxxx> wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index 94c5e18a05e0d0..467432379b91ef 100644
> > --- a/drivers/vfio/vfio.c
> > +++ b/drivers/vfio/vfio.c
> > @@ -67,6 +67,21 @@ struct vfio_unbound_dev {
> > struct list_head unbound_next;
> > };
> >
> > +/*
> > + * Virtual device without IOMMU backing. The VFIO core fakes up an
> iommu_group
> > + * as the iommu_group sysfs interface is part of the userspace ABI. The
> user
> > + * of these devices must not be able to directly trigger unmediated DMA.
> > + */
> > +#define VFIO_EMULATED_IOMMU (1 << 0)
> > +
> > +/*
> > + * Physical device without IOMMU backing. The VFIO core fakes up an
> iommu_group
> > + * as the iommu_group sysfs interface is part of the userspace ABI. Users
> can
> > + * trigger unmediated DMA by the device, usage is highly dangerous,
> requires
> > + * an explicit opt-in and will taint the kernel.
> > + */
> > +#define VFIO_NO_IOMMU (1 << 1)
> > +
> > struct vfio_group {
> > struct kref kref;
> > int minor;
> > @@ -83,7 +98,7 @@ struct vfio_group {
> > struct mutex unbound_lock;
> > atomic_t opened;
> > wait_queue_head_t container_q;
> > - bool noiommu;
> > + unsigned int flags;
>
> flags suggests to me a bit field, but we can't have EMULATED|NOIOMMU.
> Should this be an enum iommu_type?
>
and I wonder whether we should also define a type (VFIO_IOMMU)
for the remaining groups which are backed by IOMMU. This can be
set implicitly when the caller doesn't specify a specific type when
creating the group. It's not checked in any place now, but it might
be helpful for readability and diagnostic purpose? or change the
name to noiommu_flags then no confusion on its scope...
Thanks
Kevin
