Re: [RFC 2/8] iommu: Add a helper to check if any iommu device is registered

[Jacob Pan]

Hi Kevin,

On Fri, 12 Dec 2025 04:02:38 +0000
"Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> > From: Jacob Pan <jacob.pan@xxxxxxxxxxxxxxxxxxx>
> > Sent: Friday, December 5, 2025 6:07 AM
> > 
> > Hi Robin,
> > 
> > On Thu, 4 Dec 2025 10:53:36 +0000
> > Robin Murphy <robin.murphy@xxxxxxx> wrote:
> >   
> > > On 2025-12-03 10:36 pm, Jacob Pan wrote:  
> > > > Hi Jason,
> > > >
> > > > On Wed, 3 Dec 2025 09:11:29 -0400
> > > > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
> > > >  
> > > >> On Tue, Dec 02, 2025 at 04:06:35PM -0800, Jacob Pan wrote:  
> > > >>> However, as you pointed out there seems to be no standard
> > > >>> ordering for iommu device registration across platforms. e.g.
> > > >>> VT-d hooks up with x86_init, smmuv3 does that in platform
> > > >>> driver probe. This patchset puts dummy driver under
> > > >>> early_initcall which is after both but not a guarantee for
> > > >>> all platforms. Any suggestions?  
> > > >>
> > > >> I think we need to do something more like the sefltest does and
> > > >> manually bind a driver to a device so this init time ordering
> > > >> shouldn't matter.  
> > > > I have moved this dummy iommu driver init under iommufd_init(),
> > > > which aligns well since it runs after all physical IOMMU drivers
> > > > have registered. This dummy driver is intended for iommufd after
> > > > all. But I don't see a need to bind to a platform device as the
> > > > selttest does.  
> > >
> > > There is no "after all physical IOMMU drivers have registered",
> > > there is only "after we've given up waiting to see if one might
> > > be loaded as a module", but even that may be indefinite depending
> > > on build/runtime configuration.  
> > OK, how about we make loading the dummy driver an explicit user
> > opt-in, the same way as
> > /sys/module/iommufd/parameters/allow_unsafe_interrupt?  
> 
> enable_unsafe_noiommu_mode plus cdev already implies that need?
yes, i guess you meant hook up with the existing vfio knob
/sys/module/vfio/parameters/enable_unsafe_noiommu_mode

> 
> > 
> > In addition, make sure once noiommu driver is loaded, no other iommu
> > device can be registered.
> >   
> 
> this is probably the simplest way, e.g. converting below into a helper
> to add that check:
> 
> 	spin_lock(&iommu_device_lock);
> 	list_add_tail(&iommu->list, &iommu_device_list);
> 	spin_unlock(&iommu_device_lock);
> 
> called by all iommu_device_register() variants.
> 
> btw then you may need a new iommu_device_register_noiommu()
> as iommufd selftest has no such exclusiveness requirement.
> 
Yes, looks cleaner this way. iommu_device_register_noiommu() would just
fail if any other iommu devices have registered. There is no need for a
separate helper or check.

> or have a per-bus-type record to ensure each type can be only
> probed by a single driver?
That seems to be a broader change. I think it would work too. Let me
give that a try.

AFAIK, noiommu mode is only tied to PCI (due to vfio). I assume things
will stay this way.