Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 5/5/22 08:25, Shameerali Kolothum Thodi wrote: >> -Original Message- >> From: Joao Martins [mailto:joao.m.mart...@oracle.com] >> Sent: 29 April 2022 12:05 >> To: Tian, Kevin >> Cc: Joerg Roedel ; Suravee Suthikulpanit >> ; Will Deacon ; Robin >> Murphy ; Jean-Philippe Brucker >> ; zhukeqian ; >> Shameerali Kolothum Thodi ; >> David Woodhouse ; Lu Baolu >> ; Jason Gunthorpe ; Nicolin Chen >> ; Yishai Hadas ; Eric Auger >> ; Liu, Yi L ; Alex Williamson >> ; Cornelia Huck ; >> k...@vger.kernel.org; iommu@lists.linux-foundation.org >> 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 >>>> 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 iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
> -Original Message- > From: Joao Martins [mailto:joao.m.mart...@oracle.com] > Sent: 29 April 2022 12:05 > To: Tian, Kevin > Cc: Joerg Roedel ; Suravee Suthikulpanit > ; Will Deacon ; Robin > Murphy ; Jean-Philippe Brucker > ; zhukeqian ; > Shameerali Kolothum Thodi ; > David Woodhouse ; Lu Baolu > ; Jason Gunthorpe ; Nicolin Chen > ; Yishai Hadas ; Eric Auger > ; Liu, Yi L ; Alex Williamson > ; Cornelia Huck ; > k...@vger.kernel.org; iommu@lists.linux-foundation.org > 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 > >> 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. Thanks, Shameer ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
[my mua made the message a tad crooked with the quotations] On 5/2/22 12:52, Joao Martins wrote: > On 4/29/22 20:20, Robin Murphy wrote: >> On 2022-04-29 17:40, Joao Martins wrote: >>> On 4/29/22 17:11, Jason Gunthorpe wrote: On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote: > 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. Yes, I don't think a iopte walk is avoidable? >>> Correct -- exactly why I am still more learning towards enable DBM bit only >>> at start >>> versus enabling DBM at domain-creation while clearing dirty at start. >> >> I'd say it's largely down to whether you want the bother of >> communicating a dynamic behaviour change into io-pgtable. The big >> advantage of having it just use DBM all the time is that you don't have >> to do that, and the "start tracking" operation is then nothing more than >> a normal "read and clear" operation but ignoring the read result. >> >> At this point I'd much rather opt for simplicity, and leave the fancier >> stuff to revisit later if and when somebody does demonstrate a >> significant overhead from using DBM when not strictly needed. > OK -- I did get the code simplicity part[*]. Albeit my concern is that last > point: if there's anything fundamentally affecting DMA performance then > any SMMU user would see it even if they don't care at all about DBM (i.e. > regular > baremetal/non-vm iommu usage). > I can switch the SMMUv3 one to the always-enabled DBM bit. > [*] It was how I had this initially PoC-ed. And really all IOMMU drivers > dirty tracking > could be simplified to be always-enabled, and start/stop is essentially > flushing/clearing > dirties. Albeit I like that this is only really used (by hardware) when > needed and any > other DMA user isn't affected. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 4/29/22 20:20, Robin Murphy wrote: > On 2022-04-29 17:40, Joao Martins wrote: >> On 4/29/22 17:11, Jason Gunthorpe wrote: >>> On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote: 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. >>> >>> Yes, I don't think a iopte walk is avoidable? >>> >> Correct -- exactly why I am still more learning towards enable DBM bit only >> at start >> versus enabling DBM at domain-creation while clearing dirty at start. > > I'd say it's largely down to whether you want the bother of > communicating a dynamic behaviour change into io-pgtable. The big > advantage of having it just use DBM all the time is that you don't have > to do that, and the "start tracking" operation is then nothing more than > a normal "read and clear" operation but ignoring the read result. > > At this point I'd much rather opt for simplicity, and leave the fancier > stuff to revisit later if and when somebody does demonstrate a > significant overhead from using DBM when not strictly needed. > OK -- I did get the code simplicity part[*]. Albeit my concern is that last point: if there's anything fundamentally affecting DMA performance then any SMMU user would see it even if they don't care at all about DBM (i.e. regular baremetal/non-vm iommu usage). [*] It was how I had this initially PoC-ed. And really all IOMMU drivers dirty tracking could be simplified to be always-enabled, and start/stop is essentially flushing/clearing dirties. Albeit I like that this is only really used (by hardware) when needed and any other DMA user isn't affected. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 2022-04-29 17:40, Joao Martins wrote: On 4/29/22 17:11, Jason Gunthorpe wrote: On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote: 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. Yes, I don't think a iopte walk is avoidable? Correct -- exactly why I am still more learning towards enable DBM bit only at start versus enabling DBM at domain-creation while clearing dirty at start. I'd say it's largely down to whether you want the bother of communicating a dynamic behaviour change into io-pgtable. The big advantage of having it just use DBM all the time is that you don't have to do that, and the "start tracking" operation is then nothing more than a normal "read and clear" operation but ignoring the read result. At this point I'd much rather opt for simplicity, and leave the fancier stuff to revisit later if and when somebody does demonstrate a significant overhead from using DBM when not strictly needed. Thanks, Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On Fri, Apr 29, 2022 at 05:40:56PM +0100, Joao Martins wrote: > > A common use model might be to just destroy the iommu_domain without > > doing stop so prefering the clearing io page table at stop might be a > > better overall design. > > If we want to ensure that the IOPTE dirty state is immutable before start > and after stop maybe this behaviour could be a new flag in the > set-dirty-tracking > (or be implicit as you suggest). but ... hmm, at the same time, I wonder if > it's better to let userspace fetch the dirties that were there /right after > stopping/ > (via GET_DIRTY_IOVA) rather than just discarding them implicitly at > SET_DIRTY_TRACKING(0|1). It is not immutable, it is just the idea that there are no left over false-dirties after start returns. Combined with the realization that in many cases we don't need to stop, but will just destroy the whole iommu_domain Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 4/29/22 17:11, Jason Gunthorpe wrote: > On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote: >> 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. > > Yes, I don't think a iopte walk is avoidable? > Correct -- exactly why I am still more learning towards enable DBM bit only at start versus enabling DBM at domain-creation while clearing dirty at start. >> It's walking over ranges regardless. > > Also, keep in mind start should always come up in a 0 dirties state on > all platforms. So all implementations need to do something to wipe the > dirty state, either explicitly during start or restoring all clean > during stop. > > A common use model might be to just destroy the iommu_domain without > doing stop so prefering the clearing io page table at stop might be a > better overall design. If we want to ensure that the IOPTE dirty state is immutable before start and after stop maybe this behaviour could be a new flag in the set-dirty-tracking (or be implicit as you suggest). but ... hmm, at the same time, I wonder if it's better to let userspace fetch the dirties that were there /right after stopping/ (via GET_DIRTY_IOVA) rather than just discarding them implicitly at SET_DIRTY_TRACKING(0|1). ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote: > 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. Yes, I don't think a iopte walk is avoidable? > It's walking over ranges regardless. Also, keep in mind start should always come up in a 0 dirties state on all platforms. So all implementations need to do something to wipe the dirty state, either explicitly during start or restoring all clean during stop. A common use model might be to just destroy the iommu_domain without doing stop so prefering the clearing io page table at stop might be a better overall design. Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
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. 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? Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 4/29/22 12:19, Robin Murphy wrote: > On 2022-04-29 12:05, Joao Martins wrote: >> On 4/29/22 09:28, Tian, Kevin wrote: From: Joao Martins 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. >> >> I'll delete the range op, and let smmu v3 driver walk its >> own IO pgtables. > > 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. We do add the TCR values unconditionally if supported, but not the actual dirty tracking. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
On 2022-04-29 12:05, Joao Martins wrote: On 4/29/22 09:28, Tian, Kevin wrote: From: Joao Martins 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. I'll delete the range op, and let smmu v3 driver walk its own IO pgtables. 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. Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 >> 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. I'll delete the range op, and let smmu v3 driver walk its own IO pgtables. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support
> From: Joao Martins > 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. Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
