Re: [PATCH 07/14] vfio: simplify iommu group allocation for mediated devices

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 26 Aug 2021 15:34:17 +0200
Christoph Hellwig <hch@lst.de> 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?

Note that my next branch now includes the vfio-ap changes, so respins
can include the change Jason noted directly.  Thanks,

Alex