RE: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support

[Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>]

> -----Original Message-----
> From: Joao Martins [mailto:joao.m.martins@oracle.com]
> Sent: 05 May 2022 10:53
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Joerg Roedel <joro@8bytes.org>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; Will Deacon <will@kernel.org>; Robin
> Murphy <robin.murphy@arm.com>; Jean-Philippe Brucker
> <jean-philippe@linaro.org>; zhukeqian <zhukeqian1@huawei.com>; David
> Woodhouse <dwmw2@infradead.org>; Lu Baolu <baolu.lu@linux.intel.com>;
> Jason Gunthorpe <jgg@nvidia.com>; Nicolin Chen <nicolinc@nvidia.com>;
> Yishai Hadas <yishaih@nvidia.com>; Eric Auger <eric.auger@redhat.com>;
> Liu, Yi L <yi.l.liu@intel.com>; Alex Williamson
> <alex.williamson@redhat.com>; Cornelia Huck <cohuck@redhat.com>;
> kvm@vger.kernel.org; iommu@lists.linux-foundation.org; jiangkunkun
> <jiangkunkun@huawei.com>; Tian, Kevin <kevin.tian@intel.com>
> Subject: 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.martins@oracle.com]
> >> Sent: 29 April 2022 12:05
> >> To: Tian, Kevin <kevin.tian@intel.com>
> >> Cc: Joerg Roedel <joro@8bytes.org>; Suravee Suthikulpanit
> >> <suravee.suthikulpanit@amd.com>; Will Deacon <will@kernel.org>; Robin
> >> Murphy <robin.murphy@arm.com>; Jean-Philippe Brucker
> >> <jean-philippe@linaro.org>; zhukeqian <zhukeqian1@huawei.com>;
> >> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> >> David Woodhouse <dwmw2@infradead.org>; Lu Baolu
> >> <baolu.lu@linux.intel.com>; Jason Gunthorpe <jgg@nvidia.com>; Nicolin
> Chen
> >> <nicolinc@nvidia.com>; Yishai Hadas <yishaih@nvidia.com>; Eric Auger
> >> <eric.auger@redhat.com>; Liu, Yi L <yi.l.liu@intel.com>; Alex Williamson
> >> <alex.williamson@redhat.com>; Cornelia Huck <cohuck@redhat.com>;
> >> kvm@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.martins@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.
> 
> 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.

Hi Joao,

Hope soon we will have a revised spin on this series. Meantime, I tried to
hack the Qemu vSMMUv3 to emulate the support required to test this as 
access to Hardware is very limited. I manage to have a just enough setup 
to cover the ARM side of this series. Based on the test coverage I had 
and going through the code, please see my comments on few of the
patches on this series. Hope, it will be helpful when you attempt a re-spin.

Thanks,
Shameer