On 2023/8/3 12:13, Tian, Kevin wrote:
From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Thursday, August 3, 2023 12:06 PM
On 2023/8/3 12:00, Tian, Kevin wrote:
From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Thursday, August 3, 2023 11:25 AM
On 2023/8/2 15:46, Tian, Kevin wrote:
From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
Sent: Monday, July 24, 2023 7:14 PM
+
+ spin_lock_irqsave(&dmar_domain->lock, flags);
+ list_for_each_entry(info, &dmar_domain->devices, link)
+ intel_nested_invalidate(info->dev, dmar_domain,
+ req->addr, req->npages);
+ spin_unlock_irqrestore(&dmar_domain->lock, flags);
Disabling interrupt while invalidating iotlb is certainly unacceptable.
Actually there is no need to walk devices. Under dmar_domain there
is already a list of attached iommu's.
Walking device is only necessary when invalidating device TLB. For iotlb
invalidation, it only needs to know the iommu's.
even for device tlb we may think whether there is any better way
to avoid disabling interrupt. It's a slow path, especially in a guest.
I ever tried this. But some device drivers call iommu_unmap() in the
interrupt critical path. :-( So we have a long way to go.
emmm... this path only comes from iommufd and the domain is
user-managed. There won't be kernel drivers to call iommu_unmap()
on such domain.
Probably we can use a different lock for nested domain and add a comment
around the lock with above explanation.
Best regards,
baolu
