> -----Original Message-----
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 29 April 2022 12:05
> To: Tian, Kevin <kevin.t...@intel.com>
> Cc: Joerg Roedel <j...@8bytes.org>; Suravee Suthikulpanit
> <suravee.suthikulpa...@amd.com>; Will Deacon <w...@kernel.org>; Robin
> Murphy <robin.mur...@arm.com>; Jean-Philippe Brucker
> <jean-phili...@linaro.org>; zhukeqian <zhukeqi...@huawei.com>;
> Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com>;
> David Woodhouse <dw...@infradead.org>; Lu Baolu
> <baolu...@linux.intel.com>; Jason Gunthorpe <j...@nvidia.com>; Nicolin Chen
> <nicol...@nvidia.com>; Yishai Hadas <yish...@nvidia.com>; Eric Auger
> <eric.au...@redhat.com>; Liu, Yi L <yi.l....@intel.com>; Alex Williamson
> <alex.william...@redhat.com>; Cornelia Huck <coh...@redhat.com>;
> 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 <joao.m.mart...@oracle.com>
> >> 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

Reply via email to