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

[Alex Williamson <alex@shazbot.org>]

On Fri, 17 Apr 2026 10:06:09 -0700
Jacob Pan <jacob.pan@linux.microsoft.com> wrote:

> 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?

What I'm trying to point out is that vfio_null_group_allowed() is being
used in a scenario in group.c that shouldn't exist.  If all container
support is disabled, all group support should also be disabled,
regardless of no-iommu.  Otherwise we get into the scenario you show
above.  No-iommu is a feature, currently only a feature of the
group/container model, but that's what we're trying to address here.

I'm not sure what the Kconfig looks like to achieve that.

> > 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

It's a question of whether you'll break anyone.  IIRC, group-based
no-iommu works that you can enabled it, create a no-iommu group,
disabled it, and the no-iommu group continues to work.  Is it useful,
does anyone use it... I dunno.  Thanks,

Alex