On 4/29/22 13:23, Jason Gunthorpe wrote: > On Fri, Apr 29, 2022 at 01:06:06PM +0100, Joao Martins wrote: > >>> TBH I'd be inclined to just enable DBM unconditionally in >>> arm_smmu_domain_finalise() if the SMMU supports it. Trying to toggle it >>> dynamically (especially on a live domain) seems more trouble that it's >>> worth. >> >> Hmmm, but then it would strip userland/VMM from any sort of control (contrary >> to what we can do on the CPU/KVM side). e.g. the first time you do >> GET_DIRTY_IOVA it would return all dirtied IOVAs since the beginning >> of guest time, as opposed to those only after you enabled dirty-tracking. > > It just means that on SMMU the start tracking op clears all the dirty > bits. > Hmm, OK. But aren't really picking a poison here? On ARM it's the difference from switching the setting the DBM bit and put the IOPTE as writeable-clean (which is clearing another bit) versus read-and-clear-when-dirty-track-start which means we need to re-walk the pagetables to clear one bit. It's walking over ranges regardless. > I also suppose you'd also want to install the IOPTEs as dirty to > avoid a performance regression writing out new dirties for cases where > we don't dirty track? And then the start tracking op will switch this > so map creates non-dirty IOPTEs? If we end up always enabling DBM + CD.HD perhaps it makes sense for IOTLB cache the dirty-bit until we clear those bits. But really, the way this series was /trying/ to do still feels the least pain, and that way we have the same expectations from all iommus from iommufd perspective too.
