Messages in this thread | | | Subject | Re: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework | From | Keqian Zhu <> | Date | Fri, 16 Apr 2021 17:07:27 +0800 |
| |
Hi Baolu,
On 2021/4/15 18:21, Lu Baolu wrote: > Hi, > > On 2021/4/15 15:43, Keqian Zhu wrote: >>>> design it as not switchable. I will modify the commit message of patch#12, thanks! >>> I am not sure that I fully get your point. But I can't see any gaps of >>> using iommu_dev_enable/disable_feature() to switch dirty log on and off. >>> Probably I missed anything. >> IOMMU_DEV_FEAT_HWDBM just tells user whether underlying IOMMU driver supports >> dirty tracking, it is not used to management the status of dirty log tracking. >> >> The feature reporting is per device, but the status management is per iommu_domain. >> Only when all devices in a domain support HWDBM, we can start dirty log for the domain. > > So why not > > for_each_device_attached_domain() > iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM) Looks reasonable, but the problem is that we just need to enable dirty log once per domain.
> > ? >> >> And I think we'd better not mix the feature reporting and status management. Thoughts? >> > > I am worrying about having two sets of APIs for single purpose. From > vendor iommu driver's point of view, this feature is per device. Hence, > it still needs to do the same thing. Yes, we can unify the granule of feature reporting and status management.
The basic granule of dirty tracking is iommu_domain, I think it's very reasonable. We need an interface to report the feature of iommu_domain, then the logic is much more clear.
Every time we add new device or remove device from the domain, we should update the feature (e.g., maintain a counter of unsupported devices).
What do you think about this idea?
Thanks, Keqian
| |