On Tue, Jun 10, 2025 at 01:36:45PM -0700, Nicolin Chen wrote: > > I don't view this a problem for FLR, we can hold a mutex for a long > > time. It principally delays domain changes which are kind of nonsense > > to be doing concurrently with FLR in the first place.. > > > > However, for suspend, we probably want to leave a marker in the group > > IIUIC, the thing for suspend/resume is that it would result in a > long hold of the mutex, which can be a problem? Yes, it would be a confusing mess to do that.. > > that the group is force-blocked and all domain attach/detach logic > > will only update the group tracking structures and not call into the > > iommu driver. When the resume happens the core will set the current > > group domain list to the iommu driver. No need for a long lived lock > > this way. > > Yea, what we don't want is driver re-enabling ATS. So, bypassing > it at the core level should work. Then, iommu_dev_reset_prepare > and iommu_dev_reset_done will only mutex the flag. If it is easy it seems worth including. Jason
