> From: Nicolin Chen <nicolinc@xxxxxxxxxx> > Sent: Saturday, August 16, 2025 2:45 AM > > On Fri, Aug 15, 2025 at 08:55:28AM +0000, Tian, Kevin wrote: > > > From: Nicolin Chen <nicolinc@xxxxxxxxxx> > > > Sent: Tuesday, August 12, 2025 6:59 AM > > > So, iommu_get_domain_for_dev() should check the gdev flag and return > the > > > blocked domain if the flag is set. But the caller of this API could hold > > > the group->mutex already or not, making it difficult to add the lock. > > > > > > Introduce a new iommu_get_domain_for_dev_locked() helper to be used > by > > > those drivers in a context that is already under the protection of the > > > group->mutex, e.g. those attach_dev callback functions. And roll out the > > > new helper to all the existing IOMMU drivers. > > > > iommu_get_domain_for_dev() is also called outside of attach_dev > > callback functions, e.g. malidp_get_pgsize_bitmap(). and the returned > > info according to the attached domain might be saved in static > > structures, e.g.: > > > > ms->mmu_prefetch_pgsize = malidp_get_pgsize_bitmap(mp); > > > > would that cause weird issues when blocking domain is returned > > though one may not expect reset to happen at that point? > > We aren't changing the iommu_get_domain_for_dev(). So, it should > be used exclusively for functions that are outside group->mutex, > like this one, i.e. they should still get the group->domain v.s. > the blocked domain. > Usually the difference between func() and func_locked() is only about whether the caller holds a lock. If they mean to return different domains, may need better naming (though I don't have a good option now)...
