From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jacob Pan <jacob.pan@linux.microsoft.com>
Cc: linux-kernel@vger.kernel.org,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Jason Gunthorpe <jgg@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
skhawaja@google.com, pasha.tatashin@soleen.com,
Zhang Yu <zhangyu1@linux.microsoft.com>,
Jean Philippe-Brucker <jean-philippe@linaro.org>,
David Matlack <dmatlack@google.com>,
Alex Williamson <alex@shazbot.org>
Subject: Re: [RFC 2/8] iommu: Add a helper to check if any iommu device is registered
Date: Wed, 3 Dec 2025 11:31:27 +0800 [thread overview]
Message-ID: <64a01f42-9231-481a-b8f7-5c5dfed4b095@linux.intel.com> (raw)
In-Reply-To: <20251202160635.0000433e@linux.microsoft.com>
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
next prev parent reply other threads:[~2025-12-03 3:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 17:30 [RFC 0/8] iommufd: Enable noiommu mode for cdev Jacob Pan
2025-12-01 17:30 ` [RFC 1/8] iommu: Make iommu_device_register_bus available beyond selftest Jacob Pan
2025-12-01 17:30 ` [RFC 2/8] iommu: Add a helper to check if any iommu device is registered Jacob Pan
2025-12-02 2:17 ` Baolu Lu
2025-12-03 0:06 ` Jacob Pan
2025-12-03 3:31 ` Baolu Lu [this message]
2025-12-03 22:28 ` Jacob Pan
2025-12-03 13:11 ` Jason Gunthorpe
2025-12-03 22:36 ` Jacob Pan
2025-12-04 10:53 ` Robin Murphy
2025-12-04 22:07 ` Jacob Pan
2025-12-12 4:02 ` Tian, Kevin
2025-12-12 19:51 ` Jacob Pan
2025-12-01 17:30 ` [RFC 3/8] iommufd: Add a mock page table format for noiommu mode Jacob Pan
2025-12-01 17:30 ` [RFC 4/8] iommu: Add a dummy driver " Jacob Pan
2025-12-01 17:30 ` [RFC 5/8] vfio: IOMMUFD relax requirement " Jacob Pan
2025-12-12 4:05 ` Tian, Kevin
2025-12-12 19:53 ` Jacob Pan
2025-12-01 17:30 ` [RFC 6/8] vfio: Rename and remove compat from noiommu set function Jacob Pan
2025-12-01 17:30 ` [RFC 7/8] iommu: Enable cdev noiommu mode under iommufd Jacob Pan
2025-12-01 17:30 ` [RFC 8/8] iommufd: Add an ioctl IOMMU_IOAS_GET_PA to query PA from IOVA Jacob Pan
2026-01-30 19:35 ` [RFC 0/8] iommufd: Enable noiommu mode for cdev Jason Gunthorpe
2026-02-06 22:50 ` Jacob Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64a01f42-9231-481a-b8f7-5c5dfed4b095@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=alex@shazbot.org \
--cc=dmatlack@google.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=robin.murphy@arm.com \
--cc=skhawaja@google.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=zhangyu1@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox