RE: [PATCH V4 05/10] vfio: Allow null group for noiommu without containers

Tian, Kevin
2026-04-16T08:13:43Z

> From: Jacob Pan <jacob.pan@linux.microsoft.com>
> Sent: Wednesday, April 15, 2026 5:14 AM
>
> +/*
> + * With noiommu enabled and no containers are supported, allow devices
> that
> + * don't have a dummy group.
> + */
> +static inline bool vfio_null_group_allowed(void)
> +{
> + if (vfio_noiommu && (!IS_ENABLED(CONFIG_VFIO_CONTAINER)
> && !IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)))
> + return true;
> +
> + return false;
> +}

'allow' kind of implies a policy choice, but throughput this patch it's
actually a mandatory state when those conditions are true. Can we
strengthen the words here and other places to not given an impression
that even when null group is allowed it's still possible to create a vfio
group for that situation?

Just like another comment said, iommufd is the only choice in this
case, then probably could call it vfio_has_iommufd_group()?

>
> @@ -392,6 +396,16 @@ void vfio_unregister_group_dev(struct vfio_device
> *device)
> bool interrupted = false;
> long rc;
>
> + /*
> + * For noiommu devices without a container, thus no dummy group,
> + * simply delete and unregister to balance refcount.
> + */
> + if (!vfio_device_has_group(device)) {
> + vfio_device_del(device);
> + vfio_device_put_registration(device);
> + return;
> + }
> +
> /*

can you elaborate why the following wait loop is also skipped? then above
is removed by patch7 later...