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;
+}
+
 const struct iommu_ops *iommu_ops_from_fwnode(const struct fwnode_handle *fwnode)
 {
 	const struct iommu_device *iommu = iommu_from_fwnode(fwnode);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c30d12e16473..4191ae7312dd 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -933,6 +933,7 @@ extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
 extern void iommu_set_default_passthrough(bool cmd_line);
 extern void iommu_set_default_translated(bool cmd_line);
 extern bool iommu_default_passthrough(void);
+extern bool iommu_is_registered(void);
 extern struct iommu_resv_region *
 iommu_alloc_resv_region(phys_addr_t start, size_t length, int prot,
 			enum iommu_resv_type type, gfp_t gfp);
-- 
2.34.1

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

Thanks,
baolu

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?

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.

IDK maybe a fake iommu driver has too many problems :\

Jason

Hi Jason,

On Wed, 3 Dec 2025 09:11:29 -0400
Jason Gunthorpe <jgg@nvidia.com> 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.

On 2025-12-03 10:36 pm, Jacob Pan wrote:
> Hi Jason,
> 
> On Wed, 3 Dec 2025 09:11:29 -0400
> Jason Gunthorpe <jgg@nvidia.com> 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.

Thanks,
Robin.

Hi Robin,

On Thu, 4 Dec 2025 10:53:36 +0000
Robin Murphy <robin.murphy@arm.com> 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@nvidia.com> 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?

In addition, make sure once noiommu driver is loaded, no other iommu
device can be registered.

diff --git a/drivers/iommu/iommufd/device.c
b/drivers/iommu/iommufd/device.c index 4c842368289f..233e2a8a59b9 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -18,6 +18,41 @@ MODULE_PARM_DESC(
        "Allow IOMMUFD to bind to devices even if the platform cannot
isolate " "the MSI interrupt window. Enabling this is a security
weakness."); 
+static bool allow_unsafe_dma;
+
+static int allow_unsafe_dma_set(const char *val, const struct
kernel_param *kp) +{
+       int ret;
+       bool newv;
+
+       ret = kstrtobool(val, &newv);
+       if (ret)
+               return ret;
+       /* If set, call noiommu_init() to load dummy noiommu driver */
+       if (newv && !allow_unsafe_dma) {
+               /* Will fail if HW IOMMU is present */
+               ret = noiommu_init();
+               if (ret)
+                       return ret;
+               allow_unsafe_dma = newv;
+       }
+
+       return 0;
+}
+
+static int allow_unsafe_dma_get(char *buf, const struct kernel_param
*kp) +{
+    return param_get_bool(buf, kp);
+}
+
+static const struct kernel_param_ops allow_unsafe_dma_ops = {
+    .set = allow_unsafe_dma_set,
+    .get = allow_unsafe_dma_get,
+};
+
+module_param_cb(allow_unsafe_dma, &allow_unsafe_dma_ops,
&allow_unsafe_dma, 0644); +MODULE_PARM_DESC(allow_unsafe_dma, "Enable
unsafe DMA no-IOMMU mode"); +
 struct iommufd_attach {
        struct iommufd_hw_pagetable *hwpt;
        struct xarray device_array;

> From: Jacob Pan <jacob.pan@linux.microsoft.com>
> Sent: Friday, December 5, 2025 6:07 AM
> 
> Hi Robin,
> 
> On Thu, 4 Dec 2025 10:53:36 +0000
> Robin Murphy <robin.murphy@arm.com> 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@nvidia.com> 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?

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

or have a per-bus-type record to ensure each type can be only
probed by a single driver?

Hi Kevin,

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

> > From: Jacob Pan <jacob.pan@linux.microsoft.com>
> > Sent: Friday, December 5, 2025 6:07 AM
> > 
> > Hi Robin,
> > 
> > On Thu, 4 Dec 2025 10:53:36 +0000
> > Robin Murphy <robin.murphy@arm.com> 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@nvidia.com> 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.

On 12/3/25 08:06, Jacob Pan wrote:
> 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?

Could we add a helper call inside the IOMMU detection path (e.g., within
pci_iommu_alloc()) to set a flag, such as platform_iommu_present, after
successful hardware detection?

void __init pci_iommu_alloc(void)
{
         if (xen_pv_domain()) {
                 pci_xen_swiotlb_init();
                 return;
         }
         pci_swiotlb_detect();
         gart_iommu_hole_init();
         amd_iommu_detect();
         detect_intel_iommu();
         swiotlb_init(x86_swiotlb_enable, x86_swiotlb_flags);
}

Thanks,
baolu

Hi Baolu,

On Wed, 3 Dec 2025 11:31:27 +0800
Baolu Lu <baolu.lu@linux.intel.com> wrote:

> On 12/3/25 08:06, Jacob Pan wrote:
> > 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?  
> 
> Could we add a helper call inside the IOMMU detection path (e.g.,
> within pci_iommu_alloc()) to set a flag, such as
> platform_iommu_present, after successful hardware detection?
> 
> void __init pci_iommu_alloc(void)
> {
>          if (xen_pv_domain()) {
>                  pci_xen_swiotlb_init();
>                  return;
>          }
>          pci_swiotlb_detect();
>          gart_iommu_hole_init();
>          amd_iommu_detect();
>          detect_intel_iommu();
>          swiotlb_init(x86_swiotlb_enable, x86_swiotlb_flags);
> }
I think this would only work for x86.