On 5/5/22 08:25, Shameerali Kolothum Thodi wrote: >> -----Original Message----- >> From: Joao Martins [mailto:[email protected]] >> Sent: 29 April 2022 12:05 >> To: Tian, Kevin <[email protected]> >> Cc: Joerg Roedel <[email protected]>; Suravee Suthikulpanit >> <[email protected]>; Will Deacon <[email protected]>; Robin >> Murphy <[email protected]>; Jean-Philippe Brucker >> <[email protected]>; zhukeqian <[email protected]>; >> Shameerali Kolothum Thodi <[email protected]>; >> David Woodhouse <[email protected]>; Lu Baolu >> <[email protected]>; Jason Gunthorpe <[email protected]>; Nicolin Chen >> <[email protected]>; Yishai Hadas <[email protected]>; Eric Auger >> <[email protected]>; Liu, Yi L <[email protected]>; Alex Williamson >> <[email protected]>; Cornelia Huck <[email protected]>; >> [email protected]; [email protected] >> Subject: Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add >> set_dirty_tracking_range() support >> >> On 4/29/22 09:28, Tian, Kevin wrote: >>>> From: Joao Martins <[email protected]> >>>> Sent: Friday, April 29, 2022 5:09 AM >>>> >>>> Similar to .read_and_clear_dirty() use the page table >>>> walker helper functions and set DBM|RDONLY bit, thus >>>> switching the IOPTE to writeable-clean. >>> >>> this should not be one-off if the operation needs to be >>> applied to IOPTE. Say a map request comes right after >>> set_dirty_tracking() is called. If it's agreed to remove >>> the range op then smmu driver should record the tracking >>> status internally and then apply the modifier to all the new >>> mappings automatically before dirty tracking is disabled. >>> Otherwise the same logic needs to be kept in iommufd to >>> call set_dirty_tracking_range() explicitly for every new >>> iopt_area created within the tracking window. >> >> Gah, I totally missed that by mistake. New mappings aren't >> carrying over the "DBM is set". This needs a new io-pgtable >> quirk added post dirty-tracking toggling. >> >> I can adjust, but I am at odds on including this in a future >> iteration given that I can't really test any of this stuff. >> Might drop the driver until I have hardware/emulation I can >> use (or maybe others can take over this). It was included >> for revising the iommu core ops and whether iommufd was >> affected by it. > > [+Kunkun Jiang]. I think he is now looking into this and might have > a test setup to verify this.
I'll keep him CC'ed next iterations. Thanks! FWIW, the should change a bit on next iteration (simpler) by always enabling DBM from the start. SMMUv3 ::set_dirty_tracking() becomes a simpler function that tests quirks (i.e. DBM set) and what not, and calls read_and_clear_dirty() without a bitmap argument to clear dirties. _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
