Message-ID: <e42b426e-00c1-1144-4f1f-630d52f91215@redhat.com>
Date:   Fri, 15 Jan 2021 22:26:09 +0800
From:   lijiang <lijiang@...hat.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     linux-kernel@...r.kernel.org,
        "Lendacky, Thomas" <thomas.lendacky@....com>, jroedel@...e.de,
        iommu@...ts.linux-foundation.org, will@...nel.org
Subject: Re: [PATCH] iommu: check for the deferred attach when attaching a
 device

Hi, Robin

Thank you for the comment.

在 2021年01月13日 01:29, Robin Murphy 写道:
> On 2021-01-05 07:52, lijiang wrote:
>> 在 2021年01月05日 11:55, lijiang 写道:
>>> Hi,
>>>
>>> Also add Joerg to cc list.
>>>
>>
>> Also add more people to cc list, Jerry Snitselaar and Tom Lendacky.
>>
>> Thanks.
>>
>>> Thanks.
>>> Lianbo
>>> 在 2020年12月26日 13:39, Lianbo Jiang 写道:
>>>> Currently, because domain attach allows to be deferred from iommu
>>>> driver to device driver, and when iommu initializes, the devices
>>>> on the bus will be scanned and the default groups will be allocated.
>>>>
>>>> Due to the above changes, some devices could be added to the same
>>>> group as below:
>>>>
>>>> [    3.859417] pci 0000:01:00.0: Adding to iommu group 16
>>>> [    3.864572] pci 0000:01:00.1: Adding to iommu group 16
>>>> [    3.869738] pci 0000:02:00.0: Adding to iommu group 17
>>>> [    3.874892] pci 0000:02:00.1: Adding to iommu group 17
>>>>
>>>> But when attaching these devices, it doesn't allow that a group has
>>>> more than one device, otherwise it will return an error. This conflicts
>>>> with the deferred attaching. Unfortunately, it has two devices in the
>>>> same group for my side, for example:
>>>>
>>>> [    9.627014] iommu_group_device_count(): device name[0]:0000:01:00.0
>>>> [    9.633545] iommu_group_device_count(): device name[1]:0000:01:00.1
>>>> ...
>>>> [   10.255609] iommu_group_device_count(): device name[0]:0000:02:00.0
>>>> [   10.262144] iommu_group_device_count(): device name[1]:0000:02:00.1
>>>>
>>>> Finally, which caused the failure of tg3 driver when tg3 driver calls
>>>> the dma_alloc_coherent() to allocate coherent memory in the tg3_test_dma().
>>>>
>>>> [    9.660310] tg3 0000:01:00.0: DMA engine test failed, aborting
>>>> [    9.754085] tg3: probe of 0000:01:00.0 failed with error -12
>>>> [    9.997512] tg3 0000:01:00.1: DMA engine test failed, aborting
>>>> [   10.043053] tg3: probe of 0000:01:00.1 failed with error -12
>>>> [   10.288905] tg3 0000:02:00.0: DMA engine test failed, aborting
>>>> [   10.334070] tg3: probe of 0000:02:00.0 failed with error -12
>>>> [   10.578303] tg3 0000:02:00.1: DMA engine test failed, aborting
>>>> [   10.622629] tg3: probe of 0000:02:00.1 failed with error -12
>>>>
>>>> In addition, the similar situations also occur in other drivers such
>>>> as the bnxt_en driver. That can be reproduced easily in kdump kernel
>>>> when SME is active.
>>>>
>>>> Add a check for the deferred attach in the iommu_attach_device() and
>>>> allow to attach the deferred device regardless of how many devices
>>>> are in a group.
> 
> Is this iommu_attach_device() call is coming from iommu-dma? (if not, then whoever's calling it probably shouldn't be)
> 

Yes, you are right, the iommu_attach_device call is coming from iommu-dma.
 
> Assuming so, then probably what should happen is to move the handling currently in iommu_dma_deferred_attach() into the core so that it can call __iommu_attach_device() directly - the intent is just to replay that exact call skipped in iommu_group_add_device(), so the legacy external iommu_attach_device() interface isn't really the right tool for the job 

Sounds good. I will check if this can work in various cases. If it's OK, I will post again.

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index f0305e6aac1b..5e7da902ac36 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -23,7 +23,6 @@
 #include <linux/swiotlb.h>
 #include <linux/scatterlist.h>
 #include <linux/vmalloc.h>
-#include <linux/crash_dump.h>
 #include <linux/dma-direct.h>
 
 struct iommu_dma_msi_page {
@@ -378,21 +377,6 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
 	return iova_reserve_iommu_regions(dev, domain);
 }
 
-static int iommu_dma_deferred_attach(struct device *dev,
-		struct iommu_domain *domain)
-{
-	const struct iommu_ops *ops = domain->ops;
-
-	if (!is_kdump_kernel())
-		return 0;
-
-	if (unlikely(ops->is_attach_deferred &&
-			ops->is_attach_deferred(domain, dev)))
-		return iommu_attach_device(domain, dev);
-
-	return 0;
-}
-
 /**
  * dma_info_to_prot - Translate DMA API directions and attributes to IOMMU API
  *                    page flags.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ffeebda8d6de..4fed1567b498 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -23,6 +23,7 @@
 #include <linux/property.h>
 #include <linux/fsl/mc.h>
 #include <linux/module.h>
+#include <linux/crash_dump.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -1952,6 +1953,21 @@ static int __iommu_attach_device(struct iommu_domain *domain,
 	return ret;
 }
 
+int iommu_dma_deferred_attach(struct device *dev,
+                struct iommu_domain *domain)
+{
+        const struct iommu_ops *ops = domain->ops;
+
+        if (!is_kdump_kernel())
+                return 0;
+
+        if (unlikely(ops->is_attach_deferred &&
+                        ops->is_attach_deferred(domain, dev)))
+                return __iommu_attach_device(domain, dev);
+
+        return 0;
+}
+
 int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
 {
 	struct iommu_group *group;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b3f0e2018c62..8e0ee96ca456 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -424,6 +424,8 @@ extern struct iommu_group *iommu_group_get_by_id(int id);
 extern void iommu_domain_free(struct iommu_domain *domain);
 extern int iommu_attach_device(struct iommu_domain *domain,
 			       struct device *dev);
+extern int iommu_dma_deferred_attach(struct device *dev,
+                struct iommu_domain *domain);
 extern void iommu_detach_device(struct iommu_domain *domain,
 				struct device *dev);
 extern int iommu_uapi_cache_invalidate(struct iommu_domain *domain,
@@ -680,6 +682,12 @@ static inline int iommu_attach_device(struct iommu_domain *domain,
 	return -ENODEV;
 }
 
+static inline int iommu_dma_deferred_attach(struct device *dev,
+					    struct iommu_domain *domain)
+{
+	return -ENODEV;
+}
+
 static inline void iommu_detach_device(struct iommu_domain *domain,
 				       struct device *dev)
 {


> Alternatively I suppose it *could* just call ops->attach_dev directly, but then we miss out on the tracepoint, and deferred attach is arguably one of the cases where that's most useful :/
> 
Seems good, I could debug it and provide feedback.

Thanks.
Lianbo

> Robin.
> 
>>>>
>>>> Signed-off-by: Lianbo Jiang <lijiang@...hat.com>
>>>> ---
>>>>   drivers/iommu/iommu.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>> index ffeebda8d6de..dccab7b133fb 100644
>>>> --- a/drivers/iommu/iommu.c
>>>> +++ b/drivers/iommu/iommu.c
>>>> @@ -1967,8 +1967,11 @@ int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
>>>>        */
>>>>       mutex_lock(&group->mutex);
>>>>       ret = -EINVAL;
>>>> -    if (iommu_group_device_count(group) != 1)
>>>> +    if (!iommu_is_attach_deferred(domain, dev) &&
>>>> +        iommu_group_device_count(group) != 1) {
>>>> +        dev_err_ratelimited(dev, "Group has more than one device\n");
>>>>           goto out_unlock;
>>>> +    }
>>>>         ret = __iommu_attach_group(domain, group);
>>>>  
>>
>> _______________________________________________
>> iommu mailing list
>> iommu@...ts.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>
> 

Powered by blists - more mailing lists