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

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

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;