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

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

Hi Baolu,

On Tue, 2 Dec 2025 10:17:34 +0800
Baolu Lu <baolu.lu@linux.intel.com> wrote:

> Hi Jacob,
> 
> On 12/2/25 01:30, Jacob Pan wrote:
> > The dummy IOMMU driver for No-IOMMU mode should only be active when
> > no real IOMMU devices are present in the system. Introduce a helper
> > to check this condition, ensuring that the dummy driver does not
> > interfere when hardware-backed IOMMU support is available.
> > 
> > Signed-off-by: Jacob Pan<jacob.pan@linux.microsoft.com>
> > ---
> >   drivers/iommu/iommu.c | 10 ++++++++++
> >   include/linux/iommu.h |  1 +
> >   2 files changed, 11 insertions(+)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 0df914a04064..958f612bf176 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -2895,6 +2895,16 @@ static const struct iommu_device
> > *iommu_from_fwnode(const struct fwnode_handle * return ret;
> >   }
> >   
> > +bool iommu_is_registered(void)
> > +{
> > +	bool registered;
> > +
> > +	spin_lock(&iommu_device_lock);
> > +	registered = !list_empty(&iommu_device_list);
> > +	spin_unlock(&iommu_device_lock);
> > +	return registered;
> > +}  
> 
> IOMMU devices might be added by calling iommu_device_register() at any
> time. Therefore, an empty iommu_device_list does not necessarily mean
> that "no real IOMMU devices are present in the system."
Good point. My intention was that the noiommu dummy driver should
register only after all hardware IOMMU drivers have completed
registration during boot. Any subsequent registration attempt, such as a
hot-added IOMMU, should fail if noiommu mode is already active.

We could enforce this by introducing a global flag that prevents any
iommu_device from being registered after the noiommu driver has been
initialized.

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?