Messages in this thread | | | Date | Thu, 3 Aug 2023 15:36:13 +0800 | Subject | Re: [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain | From | Baolu Lu <> |
| |
On 2023/8/3 12:13, Tian, Kevin wrote: >> From: Baolu Lu <baolu.lu@linux.intel.com> >> Sent: Thursday, August 3, 2023 12:06 PM >> >> On 2023/8/3 12:00, Tian, Kevin wrote: >>>> From: Baolu Lu <baolu.lu@linux.intel.com> >>>> Sent: Thursday, August 3, 2023 11:25 AM >>>> >>>> On 2023/8/2 15:46, Tian, Kevin wrote: >>>>>> From: Liu, Yi L <yi.l.liu@intel.com> >>>>>> 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
| |