> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, May 10, 2022 9:47 PM > > On Tue, May 10, 2022 at 01:38:26AM +0000, Tian, Kevin wrote: > > > > However, tt costs nothing to have dirty tracking as long as all iommus > > > support it in the system - which seems to be the normal case today. > > > > > > We should just always turn it on at this point. > > > > Then still need a way to report " all iommus support it in the system" > > to userspace since many old systems don't support it at all. > > Userspace can query the iommu_domain directly, or 'try and fail' to > turn on tracking. > > A device capability flag is useless without a control knob to request > a domain is created with tracking, and we don't have that, or a reason > to add that. > I'm getting confused on your last comment. A capability flag has to accompany with a control knob which iiuc is what you advocated in earlier discussion i.e. specifying the tracking property when creating the domain. In this case the flag assists the userspace in deciding whether to set the property. Not sure whether we argued pass each other but here is another attempt. In general I saw three options here: a) 'try and fail' when creating the domain. It succeeds only when all iommus support tracking; b) capability reported on iommu domain. The capability is reported true only when all iommus support tracking. This allows domain property to be set after domain is created. But there is no much gain of doing so when comparing to a). c) capability reported on device. future compatible for heterogenous platform. domain property is specified at domain creation and domains can have different properties based on tracking capability of attached devices. I'm inclined to c) as it is more aligned to Robin's cleanup effort on iommu_capable() and iommu_present() in the iommu layer which moves away from global manner to per-device style. Along with that direction I guess we want to discourage adding more APIs assuming 'all iommus supporting certain capability' thing? Thanks Kevin
