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

[Jacob Pan <jacob.pan@linux.microsoft.com>]

Hi Alex,

On Thu, 16 Apr 2026 14:06:01 -0600
Alex Williamson <alex@shazbot.org> wrote:

> From: Alex Williamson <alex@shazbot.org>
> To: Jacob Pan <jacob.pan@linux.microsoft.com>
> Cc: linux-kernel@vger.kernel.org, "iommu@lists.linux.dev"
> <iommu@lists.linux.dev>, Jason Gunthorpe <jgg@nvidia.com>, Joerg
> Roedel  <joro@8bytes.org>, Mostafa Saleh <smostafa@google.com>, David
> Matlack  <dmatlack@google.com>, Robin Murphy <robin.murphy@arm.com>,
> Nicolin Chen  <nicolinc@nvidia.com>, "Tian, Kevin"
> <kevin.tian@intel.com>, Yi Liu  <yi.l.liu@intel.com>,
> skhawaja@google.com, pasha.tatashin@soleen.com, Will  Deacon
> <will@kernel.org>, Baolu Lu <baolu.lu@linux.intel.com>,
> alex@shazbot.org Subject: Re: [PATCH V4 05/10] vfio: Allow null group
> for noiommu without  containers Date: Thu, 16 Apr 2026 14:06:01 -0600
> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu)
> 
> On Tue, 14 Apr 2026 14:14:07 -0700
> Jacob Pan <jacob.pan@linux.microsoft.com> wrote:
> 
> > In case of noiommu mode is enabled for VFIO cdev without VFIO
> > container nor IOMMUFD provided compatibility container, there is no
> > need to create a dummy group. Update the group operations to
> > tolerate null group pointer.
> > 
> > Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> > 
> > ---
> > v4: (Jason)
> >    - Avoid null pointer deref in error unwind
> >    - Add null group check in vfio_device_group_unregister
> >    - repartition to include vfio_device_has_group() in this patch
> > ---
> >  drivers/vfio/group.c     | 20 ++++++++++++++++++++
> >  drivers/vfio/vfio.h      | 17 +++++++++++++++++
> >  drivers/vfio/vfio_main.c | 14 ++++++++++++++
> >  include/linux/vfio.h     |  9 +++++++++
> >  4 files changed, 60 insertions(+)
> > 
> > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > index 0fa9761b13d3..451e49d851f8 100644
> > --- a/drivers/vfio/group.c
> > +++ b/drivers/vfio/group.c
> > @@ -390,6 +390,9 @@ int vfio_device_block_group(struct vfio_device
> > *device) struct vfio_group *group = device->group;
> >  	int ret = 0;
> >  
> > +	if (vfio_null_group_allowed() && !group)
> > +		return 0;  
> 
> I think this comes down to the fact that at the end of this series,
> VFIO_NOIOMMU still depends on VFIO_GROUP.  vfio_null_group_allowed()
> can only return true if CONTAINER support is entirely disabled.  Why
> do we still select VFIO_GROUP for VFIO_NOIOMMU and build group.s when
> there's no container support to use it?
If we solve this in Kconfig, I think the dependency should be
config VFIO_GROUP
        bool "Support for the VFIO group /dev/vfio/$group_id"
+       depends on !(VFIO_NOIOMMU && !(VFIO_CONTAINER ||
  IOMMUFD_VFIO_CONTAINER))
But this causes circular dependency in that
       symbol VFIO_NOIOMMU depends on VFIO_GROUP
       symbol VFIO_GROUP depends on VFIO_NOIOMMU

If we cannot force VFIO_GROUP=n when container is entirely disabled and
NOIOMMU & cdev is enabled, then user is free to set VFIO_GROUP=y, which
creates a VFIO_GROUP that cannot be used due to lack of container.
There is no functional issue but less clean.
i.e.
#  tree /dev/vfio/    
/dev/vfio/            
|-- devices           
|   `-- noiommu-vfio0 
`-- noiommu-0         //not usable
# ls /sys/class/vfio
noiommu-0           

Maybe there is a way to force VFIO_GROUP=n w/o the circular dependency?

> Also note that vfio_noiommu is S_IWUSR, so it is mutable at runtime.
Good point, maybe we can make it a one-way latch? i.e.
 - echo 1 > .../enable_unsafe_noiommu_mode — works (n→y)
 - echo 0 > .../enable_unsafe_noiommu_mode — returns -EPERM (y→n blocked)
 - Boot param vfio.enable_unsafe_noiommu_mode=1 — works
 - Writing 1 when already 1 — no-op, succeeds