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