Hi Baolu, On Sun, 5 Mar 2023 11:05:50 +0800, Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx> wrote: > On 3/4/23 12:35 AM, Jacob Pan wrote: > >>> From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx> > >>> Sent: Thursday, March 2, 2023 10:07 PM > >>> > >>>> + > >>>> + if (hw_pass_through && domain_type_is_si(dmar_domain)) > >>>> + ret = intel_pasid_setup_pass_through(iommu, > >>>> dmar_domain, > >>>> + dev, pasid); > >>>> + else if (dmar_domain->use_first_level) > >>>> + ret = domain_setup_first_level(iommu, dmar_domain, > >>>> + dev, pasid); > >>>> + else > >>>> + ret = intel_pasid_setup_second_level(iommu, > >>>> dmar_domain, > >>>> + dev, pasid); > >>>> + > >>>> + return ret; > >>>> +} > >>> Do you need to consider pasid cache invalidation? > >>> > >> To avoid confusion this is not about invalidation of pasid cache itself > >> which should be covered by above setup functions already. > >> > >> Here actually means per-PASID invalidation in iotlb and devtlb. Today > >> only RID is tracked per domain for invalidation. it needs extension to > >> walk attached pasid too. > > Yes, will add. > > > > For the set up path, there is no need to flush IOTLBs, because we're > > going from non present to present. > > > > On the remove path, IOTLB flush should be covered when device driver > > calls iommu_detach_device_pasid(). Covered with this patch. > > It's not only for the PASID teardown path, but also for unmap(). As the > device has issued DMA requests with PASID, the IOMMU probably will cache > the DMA translation with PASID tagged. Hence, we need to invalidate the > PASID-specific IOTLB and device TLB in the unmap() path. > > I once had a patch for this: > > https://lore.kernel.org/linux-iommu/20220614034411.1634238-1-baolu.lu@xxxxxxxxxxxxxxx/ > > Probably you can use it as a starting point. understood, actually my previous version had unmap flush, based on yours as well. https://lore.kernel.org/lkml/20220518182120.1136715-1-jacob.jun.pan@xxxxxxxxxxxxxxx/T/ > > Best regards, > baolu Thanks, Jacob
