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 - 2026 Red Hat, Inc.