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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251202160635.0000433e@linux.microsoft.com>
Date: Tue, 2 Dec 2025 16:06:35 -0800
From: Jacob Pan <jacob.pan@...ux.microsoft.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, "iommu@...ts.linux.dev"
 <iommu@...ts.linux.dev>, Jason Gunthorpe <jgg@...dia.com>, Alex Williamson
 <alex.williamson@...hat.com>, Joerg Roedel <joro@...tes.org>, Will Deacon
 <will@...nel.org>, Robin Murphy <robin.murphy@....com>, Nicolin Chen
 <nicolinc@...dia.com>, "Tian, Kevin" <kevin.tian@...el.com>, "Liu, Yi L"
 <yi.l.liu@...el.com>, skhawaja@...gle.com, pasha.tatashin@...een.com, Zhang
 Yu <zhangyu1@...ux.microsoft.com>, Jean Philippe-Brucker
 <jean-philippe@...aro.org>, David Matlack <dmatlack@...gle.com>, Alex
 Williamson <alex@...zbot.org>
Subject: Re: [RFC 2/8] iommu: Add a helper to check if any iommu device is
 registered

Hi Baolu,

On Tue, 2 Dec 2025 10:17:34 +0800
Baolu Lu <baolu.lu@...ux.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@...ux.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?