> 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.
