drivers/acpi/scan.c | 7 +++++++ 1 file changed, 7 insertions(+)
Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper
probe path") broke virtio-iommu probing and no iommu group are
produced anymore.
When probe_iommu_group() gets called viommu_probe_device() fails
because viommu_get_by_fwnode(fwspec->iommu_fwnode) returns NULL.
So it seems we need to restore the original iommu_probe_device
call site in acpi_iommu_configure_id() to get a chance to probe
the device again.
Maybe this defeats the whole purpose of the original commit but
at least it fixes the virtio-iommu probing.
Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
Cc: stable@vger.kernel.org # v6.15+
Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
I also tested smmu probing and this seems to work fine.
---
drivers/acpi/scan.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index fb1fe9f3b1a3..9f4efa8f75a6 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1632,6 +1632,13 @@ static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in)
err = viot_iommu_configure(dev);
mutex_unlock(&iommu_probe_device_lock);
+ /*
+ * If we have reason to believe the IOMMU driver missed the initial
+ * iommu_probe_device() call for dev, replay it to get things in order.
+ */
+ if (!err && dev->bus)
+ err = iommu_probe_device(dev);
+
return err;
}
--
2.49.0
On 14/08/2025 3:17 pm, Eric Auger wrote: > Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper > probe path") broke virtio-iommu probing and no iommu group are > produced anymore. > > When probe_iommu_group() gets called viommu_probe_device() fails > because viommu_get_by_fwnode(fwspec->iommu_fwnode) returns NULL. ...which it's not supposed to. And *now* I remember, we never got this finished, did we? https://lore.kernel.org/linux-iommu/9beaed48da83a0882dba153e65e6cfd0a8e21482.1742484773.git.robin.murphy@arm.com/ Thanks, Robin. > So it seems we need to restore the original iommu_probe_device > call site in acpi_iommu_configure_id() to get a chance to probe > the device again. > > Maybe this defeats the whole purpose of the original commit but > at least it fixes the virtio-iommu probing. > > Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") > Cc: stable@vger.kernel.org # v6.15+ > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > --- > > I also tested smmu probing and this seems to work fine. > --- > drivers/acpi/scan.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index fb1fe9f3b1a3..9f4efa8f75a6 100644 > --- a/drivers/acpi/scan.c > +++ b/drivers/acpi/scan.c > @@ -1632,6 +1632,13 @@ static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in) > err = viot_iommu_configure(dev); > mutex_unlock(&iommu_probe_device_lock); > > + /* > + * If we have reason to believe the IOMMU driver missed the initial > + * iommu_probe_device() call for dev, replay it to get things in order. > + */ > + if (!err && dev->bus) > + err = iommu_probe_device(dev); > + > return err; > } >
Hi Robin On 8/14/25 4:53 PM, Robin Murphy wrote: > On 14/08/2025 3:17 pm, Eric Auger wrote: >> Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >> probe path") broke virtio-iommu probing and no iommu group are >> produced anymore. >> >> When probe_iommu_group() gets called viommu_probe_device() fails >> because viommu_get_by_fwnode(fwspec->iommu_fwnode) returns NULL. > > ...which it's not supposed to. And *now* I remember, we never got this > finished, did we? Seems we did not ;-) > > https://lore.kernel.org/linux-iommu/9beaed48da83a0882dba153e65e6cfd0a8e21482.1742484773.git.robin.murphy@arm.com/ > Unfortunately it does not fix my issue. Still no iommu group when booting with ACPI. Thanks Eric > > Thanks, > Robin. > >> So it seems we need to restore the original iommu_probe_device >> call site in acpi_iommu_configure_id() to get a chance to probe >> the device again. >> >> Maybe this defeats the whole purpose of the original commit but >> at least it fixes the virtio-iommu probing. >> >> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >> probe path") >> Cc: stable@vger.kernel.org # v6.15+ >> Signed-off-by: Eric Auger <eric.auger@redhat.com> >> >> --- >> >> I also tested smmu probing and this seems to work fine. >> --- >> drivers/acpi/scan.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index fb1fe9f3b1a3..9f4efa8f75a6 100644 >> --- a/drivers/acpi/scan.c >> +++ b/drivers/acpi/scan.c >> @@ -1632,6 +1632,13 @@ static int acpi_iommu_configure_id(struct >> device *dev, const u32 *id_in) >> err = viot_iommu_configure(dev); >> mutex_unlock(&iommu_probe_device_lock); >> + /* >> + * If we have reason to believe the IOMMU driver missed the initial >> + * iommu_probe_device() call for dev, replay it to get things in >> order. >> + */ >> + if (!err && dev->bus) >> + err = iommu_probe_device(dev); >> + >> return err; >> } >> >
On 14/08/2025 4:19 pm, Eric Auger wrote: > Hi Robin > > On 8/14/25 4:53 PM, Robin Murphy wrote: >> On 14/08/2025 3:17 pm, Eric Auger wrote: >>> Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >>> probe path") broke virtio-iommu probing and no iommu group are >>> produced anymore. >>> >>> When probe_iommu_group() gets called viommu_probe_device() fails >>> because viommu_get_by_fwnode(fwspec->iommu_fwnode) returns NULL. >> >> ...which it's not supposed to. And *now* I remember, we never got this >> finished, did we? > Seems we did not ;-) >> >> https://lore.kernel.org/linux-iommu/9beaed48da83a0882dba153e65e6cfd0a8e21482.1742484773.git.robin.murphy@arm.com/ >> > > Unfortunately it does not fix my issue. Still no iommu group when > booting with ACPI. Indeed the evidence at the time suggested the patch isn't quite right as-is, but that is definitely the place which needs fixing. Since Jean-Philippe's occupied with more exciting things at the moment, do you happen to have an easy recipe for testing virtio-iommu so I can try debugging it myself? Cheers, Robin. > > Thanks > > Eric >> >> Thanks, >> Robin. >> >>> So it seems we need to restore the original iommu_probe_device >>> call site in acpi_iommu_configure_id() to get a chance to probe >>> the device again. >>> >>> Maybe this defeats the whole purpose of the original commit but >>> at least it fixes the virtio-iommu probing. >>> >>> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >>> probe path") >>> Cc: stable@vger.kernel.org # v6.15+ >>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>> >>> --- >>> >>> I also tested smmu probing and this seems to work fine. >>> --- >>> drivers/acpi/scan.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >>> index fb1fe9f3b1a3..9f4efa8f75a6 100644 >>> --- a/drivers/acpi/scan.c >>> +++ b/drivers/acpi/scan.c >>> @@ -1632,6 +1632,13 @@ static int acpi_iommu_configure_id(struct >>> device *dev, const u32 *id_in) >>> err = viot_iommu_configure(dev); >>> mutex_unlock(&iommu_probe_device_lock); >>> + /* >>> + * If we have reason to believe the IOMMU driver missed the initial >>> + * iommu_probe_device() call for dev, replay it to get things in >>> order. >>> + */ >>> + if (!err && dev->bus) >>> + err = iommu_probe_device(dev); >>> + >>> return err; >>> } >>> >> >
On 8/14/25 5:28 PM, Robin Murphy wrote: > On 14/08/2025 4:19 pm, Eric Auger wrote: >> Hi Robin >> >> On 8/14/25 4:53 PM, Robin Murphy wrote: >>> On 14/08/2025 3:17 pm, Eric Auger wrote: >>>> Commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >>>> probe path") broke virtio-iommu probing and no iommu group are >>>> produced anymore. >>>> >>>> When probe_iommu_group() gets called viommu_probe_device() fails >>>> because viommu_get_by_fwnode(fwspec->iommu_fwnode) returns NULL. >>> >>> ...which it's not supposed to. And *now* I remember, we never got this >>> finished, did we? >> Seems we did not ;-) >>> >>> https://lore.kernel.org/linux-iommu/9beaed48da83a0882dba153e65e6cfd0a8e21482.1742484773.git.robin.murphy@arm.com/ >>> >>> >> >> Unfortunately it does not fix my issue. Still no iommu group when >> booting with ACPI. > > Indeed the evidence at the time suggested the patch isn't quite right > as-is, but that is definitely the place which needs fixing. Since > Jean-Philippe's occupied with more exciting things at the moment, do > you happen to have an easy recipe for testing virtio-iommu so I can > try debugging it myself? No easy recipe. on my end I am using qemu/kvm with a rhel guest and custom kernel. I guess it was integrated in kvmtool, wasn't it? I am just testing with protected virtio devices. Thanks Eric > > Cheers, > Robin. > >> >> Thanks >> >> Eric >>> >>> Thanks, >>> Robin. >>> >>>> So it seems we need to restore the original iommu_probe_device >>>> call site in acpi_iommu_configure_id() to get a chance to probe >>>> the device again. >>>> >>>> Maybe this defeats the whole purpose of the original commit but >>>> at least it fixes the virtio-iommu probing. >>>> >>>> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper >>>> probe path") >>>> Cc: stable@vger.kernel.org # v6.15+ >>>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>>> >>>> --- >>>> >>>> I also tested smmu probing and this seems to work fine. >>>> --- >>>> drivers/acpi/scan.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >>>> index fb1fe9f3b1a3..9f4efa8f75a6 100644 >>>> --- a/drivers/acpi/scan.c >>>> +++ b/drivers/acpi/scan.c >>>> @@ -1632,6 +1632,13 @@ static int acpi_iommu_configure_id(struct >>>> device *dev, const u32 *id_in) >>>> err = viot_iommu_configure(dev); >>>> mutex_unlock(&iommu_probe_device_lock); >>>> + /* >>>> + * If we have reason to believe the IOMMU driver missed the >>>> initial >>>> + * iommu_probe_device() call for dev, replay it to get things in >>>> order. >>>> + */ >>>> + if (!err && dev->bus) >>>> + err = iommu_probe_device(dev); >>>> + >>>> return err; >>>> } >>>> >>> >> >
© 2016 - 2025 Red Hat, Inc.