All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Joao Martins <joao.m.martins@oracle.com>,
	iommu@lists.linux-foundation.org
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>,
	Keqian Zhu <zhukeqian1@huawei.com>,
	Shameerali Kolothum Thodi  <shameerali.kolothum.thodi@huawei.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Eric Auger <eric.auger@redhat.com>, Yi Liu <yi.l.liu@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH RFC 01/19] iommu: Add iommu_domain ops for dirty tracking
Date: Fri, 29 Apr 2022 21:40:19 +0800	[thread overview]
Message-ID: <2d369e58-8ac0-f263-7b94-fe73917782e1@linux.intel.com> (raw)
In-Reply-To: <20220428210933.3583-2-joao.m.martins@oracle.com>

Hi Joao,

Thanks for doing this.

On 2022/4/29 05:09, Joao Martins wrote:
> Add to iommu domain operations a set of callbacks to
> perform dirty tracking, particulary to start and stop
> tracking and finally to test and clear the dirty data.
> 
> Drivers are expected to dynamically change its hw protection
> domain bits to toggle the tracking and flush some form of
> control state structure that stands in the IOVA translation
> path.
> 
> For reading and clearing dirty data, in all IOMMUs a transition
> from any of the PTE access bits (Access, Dirty) implies flushing
> the IOTLB to invalidate any stale data in the IOTLB as to whether
> or not the IOMMU should update the said PTEs. The iommu core APIs
> introduce a new structure for storing the dirties, albeit vendor
> IOMMUs implementing .read_and_clear_dirty() just use
> iommu_dirty_bitmap_record() to set the memory storing dirties.
> The underlying tracking/iteration of user bitmap memory is instead
> done by iommufd which takes care of initializing the dirty bitmap
> *prior* to passing to the IOMMU domain op.
> 
> So far for currently/to-be-supported IOMMUs with dirty tracking
> support this particularly because the tracking is part of
> first stage tables and part of address translation. Below
> it is mentioned how hardware deal with the hardware protection
> domain control bits, to justify the added iommu core APIs.
> vendor IOMMU implementation will also explain in more detail on
> the dirty bit usage/clearing in the IOPTEs.
> 
> * x86 AMD:
> 
> The same thing for AMD particularly the Device Table
> respectivally, followed by flushing the Device IOTLB. On AMD[1],
> section "2.2.1 Updating Shared Tables", e.g.
> 
>> Each table can also have its contents cached by the IOMMU or
> peripheral IOTLBs. Therefore, after
> updating a table entry that can be cached, system software must
> send the IOMMU an appropriate
> invalidate command. Information in the peripheral IOTLBs must
> also be invalidated.
> 
> There's no mention of particular bits that are cached or
> not but fetching a dev entry is part of address translation
> as also depicted, so invalidate the device table to make
> sure the next translations fetch a DTE entry with the HD bits set.
> 
> * x86 Intel (rev3.0+):
> 
> Likewise[2] set the SSADE bit in the scalable-entry second stage table
> to enable Access/Dirty bits in the second stage page table. See manual,
> particularly on "6.2.3.1 Scalable-Mode PASID-Table Entry Programming
> Considerations"
> 
>> When modifying root-entries, scalable-mode root-entries,
> context-entries, or scalable-mode context
> entries:
>> Software must serially invalidate the context-cache,
> PASID-cache (if applicable), and the IOTLB.  The serialization is
> required since hardware may utilize information from the
> context-caches (e.g., Domain-ID) to tag new entries inserted to
> the PASID-cache and IOTLB for processing in-flight requests.
> Section 6.5 describe the invalidation operations.
> 
> And also the whole chapter "" Table "Table 23.  Guidance to
> Software for Invalidations" in "6.5.3.3 Guidance to Software for
> Invalidations" explicitly mentions
> 
>> SSADE transition from 0 to 1 in a scalable-mode PASID-table
> entry with PGTT value of Second-stage or Nested
> 
> * ARM SMMUV3.2:
> 
> SMMUv3.2 needs to toggle the dirty bit descriptor
> over the CD (or S2CD) for toggling and flush/invalidate
> the IOMMU dev IOTLB.
> 
> Reference[0]: SMMU spec, "5.4.1 CD notes",
> 
>> The following CD fields are permitted to be cached as part of a
> translation or TLB entry, and alteration requires
> invalidation of any TLB entry that might have cached these
> fields, in addition to CD structure cache invalidation:
> 
> ...
> HA, HD
> ...
> 
> Although, The ARM SMMUv3 case is a tad different that its x86
> counterparts. Rather than changing *only* the IOMMU domain device entry to
> enable dirty tracking (and having a dedicated bit for dirtyness in IOPTE)
> ARM instead uses a dirty-bit modifier which is separately enabled, and
> changes the *existing* meaning of access bits (for ro/rw), to the point
> that marking access bit read-only but with dirty-bit-modifier enabled
> doesn't trigger an perm io page fault.
> 
> In pratice this means that changing iommu context isn't enough
> and in fact mostly useless IIUC (and can be always enabled). Dirtying
> is only really enabled when the DBM pte bit is enabled (with the
> CD.HD bit as a prereq).
> 
> To capture this h/w construct an iommu core API is added which enables
> dirty tracking on an IOVA range rather than a device/context entry.
> iommufd picks one or the other, and IOMMUFD core will favour
> device-context op followed by IOVA-range alternative.

Instead of specification words, I'd like to read more about why the
callbacks are needed and how should they be implemented and consumed.

> 
> [0] https://developer.arm.com/documentation/ihi0070/latest
> [1] https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf
> [2] https://cdrdv2.intel.com/v1/dl/getContent/671081
> 
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
>   drivers/iommu/iommu.c      | 28 ++++++++++++++++++++
>   include/linux/io-pgtable.h |  6 +++++
>   include/linux/iommu.h      | 52 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 0c42ece25854..d18b9ddbcce4 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -15,6 +15,7 @@
>   #include <linux/init.h>
>   #include <linux/export.h>
>   #include <linux/slab.h>
> +#include <linux/highmem.h>
>   #include <linux/errno.h>
>   #include <linux/iommu.h>
>   #include <linux/idr.h>
> @@ -3167,3 +3168,30 @@ bool iommu_group_dma_owner_claimed(struct iommu_group *group)
>   	return user;
>   }
>   EXPORT_SYMBOL_GPL(iommu_group_dma_owner_claimed);
> +
> +unsigned int iommu_dirty_bitmap_record(struct iommu_dirty_bitmap *dirty,
> +				       unsigned long iova, unsigned long length)
> +{
> +	unsigned long nbits, offset, start_offset, idx, size, *kaddr;
> +
> +	nbits = max(1UL, length >> dirty->pgshift);
> +	offset = (iova - dirty->iova) >> dirty->pgshift;
> +	idx = offset / (PAGE_SIZE * BITS_PER_BYTE);
> +	offset = offset % (PAGE_SIZE * BITS_PER_BYTE);
> +	start_offset = dirty->start_offset;
> +
> +	while (nbits > 0) {
> +		kaddr = kmap(dirty->pages[idx]) + start_offset;
> +		size = min(PAGE_SIZE * BITS_PER_BYTE - offset, nbits);
> +		bitmap_set(kaddr, offset, size);
> +		kunmap(dirty->pages[idx]);
> +		start_offset = offset = 0;
> +		nbits -= size;
> +		idx++;
> +	}
> +
> +	if (dirty->gather)
> +		iommu_iotlb_gather_add_range(dirty->gather, iova, length);
> +
> +	return nbits;
> +}
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 86af6f0a00a2..82b39925c21f 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -165,6 +165,12 @@ struct io_pgtable_ops {
>   			      struct iommu_iotlb_gather *gather);
>   	phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
>   				    unsigned long iova);
> +	int (*set_dirty_tracking)(struct io_pgtable_ops *ops,
> +				  unsigned long iova, size_t size,
> +				  bool enabled);
> +	int (*read_and_clear_dirty)(struct io_pgtable_ops *ops,
> +				    unsigned long iova, size_t size,
> +				    struct iommu_dirty_bitmap *dirty);
>   };
>   
>   /**
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 6ef2df258673..ca076365d77b 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -189,6 +189,25 @@ struct iommu_iotlb_gather {
>   	bool			queued;
>   };
>   
> +/**
> + * struct iommu_dirty_bitmap - Dirty IOVA bitmap state
> + *
> + * @iova: IOVA representing the start of the bitmap, the first bit of the bitmap
> + * @pgshift: Page granularity of the bitmap
> + * @gather: Range information for a pending IOTLB flush
> + * @start_offset: Offset of the first user page
> + * @pages: User pages representing the bitmap region
> + * @npages: Number of user pages pinned
> + */
> +struct iommu_dirty_bitmap {
> +	unsigned long iova;
> +	unsigned long pgshift;
> +	struct iommu_iotlb_gather *gather;
> +	unsigned long start_offset;
> +	unsigned long npages;

I haven't found where "npages" is used in this patch. It's better to add
it when it's really used? Sorry if I missed anything.

> +	struct page **pages;
> +};
> +
>   /**
>    * struct iommu_ops - iommu ops and capabilities
>    * @capable: check capability
> @@ -275,6 +294,13 @@ struct iommu_ops {
>    * @enable_nesting: Enable nesting
>    * @set_pgtable_quirks: Set io page table quirks (IO_PGTABLE_QUIRK_*)
>    * @free: Release the domain after use.
> + * @set_dirty_tracking: Enable or Disable dirty tracking on the iommu domain
> + * @set_dirty_tracking_range: Enable or Disable dirty tracking on a range of
> + *                            an iommu domain
> + * @read_and_clear_dirty: Walk IOMMU page tables for dirtied PTEs marshalled
> + *                        into a bitmap, with a bit represented as a page.
> + *                        Reads the dirty PTE bits and clears it from IO
> + *                        pagetables.
>    */
>   struct iommu_domain_ops {
>   	int (*attach_dev)(struct iommu_domain *domain, struct device *dev);
> @@ -305,6 +331,15 @@ struct iommu_domain_ops {
>   				  unsigned long quirks);
>   
>   	void (*free)(struct iommu_domain *domain);
> +
> +	int (*set_dirty_tracking)(struct iommu_domain *domain, bool enabled);
> +	int (*set_dirty_tracking_range)(struct iommu_domain *domain,
> +					unsigned long iova, size_t size,
> +					struct iommu_iotlb_gather *iotlb_gather,
> +					bool enabled);

It seems that we are adding two callbacks for the same purpose. How
should the IOMMU drivers select to support? Any functional different
between these two? How should the caller select to use?

> +	int (*read_and_clear_dirty)(struct iommu_domain *domain,
> +				    unsigned long iova, size_t size,
> +				    struct iommu_dirty_bitmap *dirty);
>   };
>   
>   /**
> @@ -494,6 +529,23 @@ void iommu_set_dma_strict(void);
>   extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
>   			      unsigned long iova, int flags);
>   
> +unsigned int iommu_dirty_bitmap_record(struct iommu_dirty_bitmap *dirty,
> +				       unsigned long iova, unsigned long length);
> +
> +static inline void iommu_dirty_bitmap_init(struct iommu_dirty_bitmap *dirty,
> +					   unsigned long base,
> +					   unsigned long pgshift,
> +					   struct iommu_iotlb_gather *gather)
> +{
> +	memset(dirty, 0, sizeof(*dirty));
> +	dirty->iova = base;
> +	dirty->pgshift = pgshift;
> +	dirty->gather = gather;
> +
> +	if (gather)
> +		iommu_iotlb_gather_init(dirty->gather);
> +}
> +
>   static inline void iommu_flush_iotlb_all(struct iommu_domain *domain)
>   {
>   	if (domain->ops->flush_iotlb_all)

Best regards,
baolu

WARNING: multiple messages have this Message-ID (diff)
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Joao Martins <joao.m.martins@oracle.com>,
	iommu@lists.linux-foundation.org
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Cornelia Huck <cohuck@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH RFC 01/19] iommu: Add iommu_domain ops for dirty tracking
Date: Fri, 29 Apr 2022 21:40:19 +0800	[thread overview]
Message-ID: <2d369e58-8ac0-f263-7b94-fe73917782e1@linux.intel.com> (raw)
In-Reply-To: <20220428210933.3583-2-joao.m.martins@oracle.com>

Hi Joao,

Thanks for doing this.

On 2022/4/29 05:09, Joao Martins wrote:
> Add to iommu domain operations a set of callbacks to
> perform dirty tracking, particulary to start and stop
> tracking and finally to test and clear the dirty data.
> 
> Drivers are expected to dynamically change its hw protection
> domain bits to toggle the tracking and flush some form of
> control state structure that stands in the IOVA translation
> path.
> 
> For reading and clearing dirty data, in all IOMMUs a transition
> from any of the PTE access bits (Access, Dirty) implies flushing
> the IOTLB to invalidate any stale data in the IOTLB as to whether
> or not the IOMMU should update the said PTEs. The iommu core APIs
> introduce a new structure for storing the dirties, albeit vendor
> IOMMUs implementing .read_and_clear_dirty() just use
> iommu_dirty_bitmap_record() to set the memory storing dirties.
> The underlying tracking/iteration of user bitmap memory is instead
> done by iommufd which takes care of initializing the dirty bitmap
> *prior* to passing to the IOMMU domain op.
> 
> So far for currently/to-be-supported IOMMUs with dirty tracking
> support this particularly because the tracking is part of
> first stage tables and part of address translation. Below
> it is mentioned how hardware deal with the hardware protection
> domain control bits, to justify the added iommu core APIs.
> vendor IOMMU implementation will also explain in more detail on
> the dirty bit usage/clearing in the IOPTEs.
> 
> * x86 AMD:
> 
> The same thing for AMD particularly the Device Table
> respectivally, followed by flushing the Device IOTLB. On AMD[1],
> section "2.2.1 Updating Shared Tables", e.g.
> 
>> Each table can also have its contents cached by the IOMMU or
> peripheral IOTLBs. Therefore, after
> updating a table entry that can be cached, system software must
> send the IOMMU an appropriate
> invalidate command. Information in the peripheral IOTLBs must
> also be invalidated.
> 
> There's no mention of particular bits that are cached or
> not but fetching a dev entry is part of address translation
> as also depicted, so invalidate the device table to make
> sure the next translations fetch a DTE entry with the HD bits set.
> 
> * x86 Intel (rev3.0+):
> 
> Likewise[2] set the SSADE bit in the scalable-entry second stage table
> to enable Access/Dirty bits in the second stage page table. See manual,
> particularly on "6.2.3.1 Scalable-Mode PASID-Table Entry Programming
> Considerations"
> 
>> When modifying root-entries, scalable-mode root-entries,
> context-entries, or scalable-mode context
> entries:
>> Software must serially invalidate the context-cache,
> PASID-cache (if applicable), and the IOTLB.  The serialization is
> required since hardware may utilize information from the
> context-caches (e.g., Domain-ID) to tag new entries inserted to
> the PASID-cache and IOTLB for processing in-flight requests.
> Section 6.5 describe the invalidation operations.
> 
> And also the whole chapter "" Table "Table 23.  Guidance to
> Software for Invalidations" in "6.5.3.3 Guidance to Software for
> Invalidations" explicitly mentions
> 
>> SSADE transition from 0 to 1 in a scalable-mode PASID-table
> entry with PGTT value of Second-stage or Nested
> 
> * ARM SMMUV3.2:
> 
> SMMUv3.2 needs to toggle the dirty bit descriptor
> over the CD (or S2CD) for toggling and flush/invalidate
> the IOMMU dev IOTLB.
> 
> Reference[0]: SMMU spec, "5.4.1 CD notes",
> 
>> The following CD fields are permitted to be cached as part of a
> translation or TLB entry, and alteration requires
> invalidation of any TLB entry that might have cached these
> fields, in addition to CD structure cache invalidation:
> 
> ...
> HA, HD
> ...
> 
> Although, The ARM SMMUv3 case is a tad different that its x86
> counterparts. Rather than changing *only* the IOMMU domain device entry to
> enable dirty tracking (and having a dedicated bit for dirtyness in IOPTE)
> ARM instead uses a dirty-bit modifier which is separately enabled, and
> changes the *existing* meaning of access bits (for ro/rw), to the point
> that marking access bit read-only but with dirty-bit-modifier enabled
> doesn't trigger an perm io page fault.
> 
> In pratice this means that changing iommu context isn't enough
> and in fact mostly useless IIUC (and can be always enabled). Dirtying
> is only really enabled when the DBM pte bit is enabled (with the
> CD.HD bit as a prereq).
> 
> To capture this h/w construct an iommu core API is added which enables
> dirty tracking on an IOVA range rather than a device/context entry.
> iommufd picks one or the other, and IOMMUFD core will favour
> device-context op followed by IOVA-range alternative.

Instead of specification words, I'd like to read more about why the
callbacks are needed and how should they be implemented and consumed.

> 
> [0] https://developer.arm.com/documentation/ihi0070/latest
> [1] https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf
> [2] https://cdrdv2.intel.com/v1/dl/getContent/671081
> 
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
>   drivers/iommu/iommu.c      | 28 ++++++++++++++++++++
>   include/linux/io-pgtable.h |  6 +++++
>   include/linux/iommu.h      | 52 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 0c42ece25854..d18b9ddbcce4 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -15,6 +15,7 @@
>   #include <linux/init.h>
>   #include <linux/export.h>
>   #include <linux/slab.h>
> +#include <linux/highmem.h>
>   #include <linux/errno.h>
>   #include <linux/iommu.h>
>   #include <linux/idr.h>
> @@ -3167,3 +3168,30 @@ bool iommu_group_dma_owner_claimed(struct iommu_group *group)
>   	return user;
>   }
>   EXPORT_SYMBOL_GPL(iommu_group_dma_owner_claimed);
> +
> +unsigned int iommu_dirty_bitmap_record(struct iommu_dirty_bitmap *dirty,
> +				       unsigned long iova, unsigned long length)
> +{
> +	unsigned long nbits, offset, start_offset, idx, size, *kaddr;
> +
> +	nbits = max(1UL, length >> dirty->pgshift);
> +	offset = (iova - dirty->iova) >> dirty->pgshift;
> +	idx = offset / (PAGE_SIZE * BITS_PER_BYTE);
> +	offset = offset % (PAGE_SIZE * BITS_PER_BYTE);
> +	start_offset = dirty->start_offset;
> +
> +	while (nbits > 0) {
> +		kaddr = kmap(dirty->pages[idx]) + start_offset;
> +		size = min(PAGE_SIZE * BITS_PER_BYTE - offset, nbits);
> +		bitmap_set(kaddr, offset, size);
> +		kunmap(dirty->pages[idx]);
> +		start_offset = offset = 0;
> +		nbits -= size;
> +		idx++;
> +	}
> +
> +	if (dirty->gather)
> +		iommu_iotlb_gather_add_range(dirty->gather, iova, length);
> +
> +	return nbits;
> +}
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 86af6f0a00a2..82b39925c21f 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -165,6 +165,12 @@ struct io_pgtable_ops {
>   			      struct iommu_iotlb_gather *gather);
>   	phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
>   				    unsigned long iova);
> +	int (*set_dirty_tracking)(struct io_pgtable_ops *ops,
> +				  unsigned long iova, size_t size,
> +				  bool enabled);
> +	int (*read_and_clear_dirty)(struct io_pgtable_ops *ops,
> +				    unsigned long iova, size_t size,
> +				    struct iommu_dirty_bitmap *dirty);
>   };
>   
>   /**
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 6ef2df258673..ca076365d77b 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -189,6 +189,25 @@ struct iommu_iotlb_gather {
>   	bool			queued;
>   };
>   
> +/**
> + * struct iommu_dirty_bitmap - Dirty IOVA bitmap state
> + *
> + * @iova: IOVA representing the start of the bitmap, the first bit of the bitmap
> + * @pgshift: Page granularity of the bitmap
> + * @gather: Range information for a pending IOTLB flush
> + * @start_offset: Offset of the first user page
> + * @pages: User pages representing the bitmap region
> + * @npages: Number of user pages pinned
> + */
> +struct iommu_dirty_bitmap {
> +	unsigned long iova;
> +	unsigned long pgshift;
> +	struct iommu_iotlb_gather *gather;
> +	unsigned long start_offset;
> +	unsigned long npages;

I haven't found where "npages" is used in this patch. It's better to add
it when it's really used? Sorry if I missed anything.

> +	struct page **pages;
> +};
> +
>   /**
>    * struct iommu_ops - iommu ops and capabilities
>    * @capable: check capability
> @@ -275,6 +294,13 @@ struct iommu_ops {
>    * @enable_nesting: Enable nesting
>    * @set_pgtable_quirks: Set io page table quirks (IO_PGTABLE_QUIRK_*)
>    * @free: Release the domain after use.
> + * @set_dirty_tracking: Enable or Disable dirty tracking on the iommu domain
> + * @set_dirty_tracking_range: Enable or Disable dirty tracking on a range of
> + *                            an iommu domain
> + * @read_and_clear_dirty: Walk IOMMU page tables for dirtied PTEs marshalled
> + *                        into a bitmap, with a bit represented as a page.
> + *                        Reads the dirty PTE bits and clears it from IO
> + *                        pagetables.
>    */
>   struct iommu_domain_ops {
>   	int (*attach_dev)(struct iommu_domain *domain, struct device *dev);
> @@ -305,6 +331,15 @@ struct iommu_domain_ops {
>   				  unsigned long quirks);
>   
>   	void (*free)(struct iommu_domain *domain);
> +
> +	int (*set_dirty_tracking)(struct iommu_domain *domain, bool enabled);
> +	int (*set_dirty_tracking_range)(struct iommu_domain *domain,
> +					unsigned long iova, size_t size,
> +					struct iommu_iotlb_gather *iotlb_gather,
> +					bool enabled);

It seems that we are adding two callbacks for the same purpose. How
should the IOMMU drivers select to support? Any functional different
between these two? How should the caller select to use?

> +	int (*read_and_clear_dirty)(struct iommu_domain *domain,
> +				    unsigned long iova, size_t size,
> +				    struct iommu_dirty_bitmap *dirty);
>   };
>   
>   /**
> @@ -494,6 +529,23 @@ void iommu_set_dma_strict(void);
>   extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
>   			      unsigned long iova, int flags);
>   
> +unsigned int iommu_dirty_bitmap_record(struct iommu_dirty_bitmap *dirty,
> +				       unsigned long iova, unsigned long length);
> +
> +static inline void iommu_dirty_bitmap_init(struct iommu_dirty_bitmap *dirty,
> +					   unsigned long base,
> +					   unsigned long pgshift,
> +					   struct iommu_iotlb_gather *gather)
> +{
> +	memset(dirty, 0, sizeof(*dirty));
> +	dirty->iova = base;
> +	dirty->pgshift = pgshift;
> +	dirty->gather = gather;
> +
> +	if (gather)
> +		iommu_iotlb_gather_init(dirty->gather);
> +}
> +
>   static inline void iommu_flush_iotlb_all(struct iommu_domain *domain)
>   {
>   	if (domain->ops->flush_iotlb_all)

Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2022-04-29 13:40 UTC|newest]

Thread overview: 209+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 21:09 [PATCH RFC 00/19] IOMMUFD Dirty Tracking Joao Martins
2022-04-28 21:09 ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 01/19] iommu: Add iommu_domain ops for dirty tracking Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  7:54   ` Tian, Kevin
2022-04-29  7:54     ` Tian, Kevin
2022-04-29 10:44     ` Joao Martins
2022-04-29 10:44       ` Joao Martins
2022-04-29 12:08   ` Jason Gunthorpe
2022-04-29 12:08     ` Jason Gunthorpe via iommu
2022-04-29 14:26     ` Joao Martins
2022-04-29 14:26       ` Joao Martins
2022-04-29 14:35       ` Jason Gunthorpe
2022-04-29 14:35         ` Jason Gunthorpe via iommu
2022-04-29 13:40   ` Baolu Lu [this message]
2022-04-29 13:40     ` Baolu Lu
2022-04-29 15:27     ` Joao Martins
2022-04-29 15:27       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 02/19] iommufd: Dirty tracking for io_pagetable Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  8:07   ` Tian, Kevin
2022-04-29  8:07     ` Tian, Kevin
2022-04-29 10:48     ` Joao Martins
2022-04-29 10:48       ` Joao Martins
2022-04-29 11:56     ` Jason Gunthorpe
2022-04-29 11:56       ` Jason Gunthorpe via iommu
2022-04-29 14:28       ` Joao Martins
2022-04-29 14:28         ` Joao Martins
2022-04-29 23:51   ` Baolu Lu
2022-04-29 23:51     ` Baolu Lu
2022-05-02 11:57     ` Joao Martins
2022-05-02 11:57       ` Joao Martins
2022-08-29 10:01   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 03/19] iommufd: Dirty tracking data support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  8:12   ` Tian, Kevin
2022-04-29  8:12     ` Tian, Kevin
2022-04-29 10:54     ` Joao Martins
2022-04-29 10:54       ` Joao Martins
2022-04-29 12:09       ` Jason Gunthorpe
2022-04-29 12:09         ` Jason Gunthorpe via iommu
2022-04-29 14:33         ` Joao Martins
2022-04-29 14:33           ` Joao Martins
2022-04-30  4:11   ` Baolu Lu
2022-04-30  4:11     ` Baolu Lu
2022-05-02 12:06     ` Joao Martins
2022-05-02 12:06       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 04/19] iommu: Add an unmap API that returns dirtied IOPTEs Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-30  5:12   ` Baolu Lu
2022-04-30  5:12     ` Baolu Lu
2022-05-02 12:22     ` Joao Martins
2022-05-02 12:22       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 05/19] iommufd: Add a dirty bitmap to iopt_unmap_iova() Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29 12:14   ` Jason Gunthorpe
2022-04-29 12:14     ` Jason Gunthorpe via iommu
2022-04-29 14:36     ` Joao Martins
2022-04-29 14:36       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 06/19] iommufd: Dirty tracking IOCTLs for the hw_pagetable Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 07/19] iommufd/vfio-compat: Dirty tracking IOCTLs compatibility Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29 12:19   ` Jason Gunthorpe
2022-04-29 12:19     ` Jason Gunthorpe via iommu
2022-04-29 14:27     ` Joao Martins
2022-04-29 14:27       ` Joao Martins
2022-04-29 14:36       ` Jason Gunthorpe via iommu
2022-04-29 14:36         ` Jason Gunthorpe
2022-04-29 14:52         ` Joao Martins
2022-04-29 14:52           ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 08/19] iommufd: Add a test for dirty tracking ioctls Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 09/19] iommu/amd: Access/Dirty bit support in IOPTEs Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-05-31 11:34   ` Suravee Suthikulpanit via iommu
2022-05-31 11:34     ` Suravee Suthikulpanit
2022-05-31 12:15     ` Baolu Lu
2022-05-31 12:15       ` Baolu Lu
2022-05-31 15:22     ` Joao Martins
2022-05-31 15:22       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 10/19] iommu/amd: Add unmap_read_dirty() support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-05-31 12:39   ` Suravee Suthikulpanit
2022-05-31 12:39     ` Suravee Suthikulpanit via iommu
2022-05-31 15:51     ` Joao Martins
2022-05-31 15:51       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 11/19] iommu/amd: Print access/dirty bits if supported Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 12/19] iommu/arm-smmu-v3: Add feature detection for HTTU Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 13/19] iommu/arm-smmu-v3: Add feature detection for BBML Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29 11:11   ` Robin Murphy
2022-04-29 11:11     ` Robin Murphy
2022-04-29 11:54     ` Joao Martins
2022-04-29 11:54       ` Joao Martins
2022-04-29 12:26       ` Robin Murphy
2022-04-29 12:26         ` Robin Murphy
2022-04-29 14:34         ` Joao Martins
2022-04-29 14:34           ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 14/19] iommu/arm-smmu-v3: Add read_and_clear_dirty() support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-08-29  9:59   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  8:28   ` Tian, Kevin
2022-04-29  8:28     ` Tian, Kevin
2022-04-29 11:05     ` Joao Martins
2022-04-29 11:05       ` Joao Martins
2022-04-29 11:19       ` Robin Murphy
2022-04-29 11:19         ` Robin Murphy
2022-04-29 12:06         ` Joao Martins
2022-04-29 12:06           ` Joao Martins
2022-04-29 12:23           ` Jason Gunthorpe
2022-04-29 12:23             ` Jason Gunthorpe via iommu
2022-04-29 14:45             ` Joao Martins
2022-04-29 14:45               ` Joao Martins
2022-04-29 16:11               ` Jason Gunthorpe
2022-04-29 16:11                 ` Jason Gunthorpe via iommu
2022-04-29 16:40                 ` Joao Martins
2022-04-29 16:40                   ` Joao Martins
2022-04-29 16:46                   ` Jason Gunthorpe
2022-04-29 16:46                     ` Jason Gunthorpe via iommu
2022-04-29 19:20                   ` Robin Murphy
2022-04-29 19:20                     ` Robin Murphy
2022-05-02 11:52                     ` Joao Martins
2022-05-02 11:52                       ` Joao Martins
2022-05-02 11:57                       ` Joao Martins
2022-05-02 11:57                         ` Joao Martins
2022-05-05  7:25       ` Shameerali Kolothum Thodi
2022-05-05  7:25         ` Shameerali Kolothum Thodi via iommu
2022-05-05  9:52         ` Joao Martins
2022-05-05  9:52           ` Joao Martins
2022-08-29  9:59           ` Shameerali Kolothum Thodi
2022-08-29 10:00   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 16/19] iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mapping Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29 11:35   ` Robin Murphy
2022-04-29 11:35     ` Robin Murphy
2022-04-29 12:10     ` Joao Martins
2022-04-29 12:10       ` Joao Martins
2022-04-29 12:46       ` Robin Murphy
2022-04-29 12:46         ` Robin Murphy
2022-08-29 10:00   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 17/19] iommu/arm-smmu-v3: Add unmap_read_dirty() support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29 11:53   ` Robin Murphy
2022-04-29 11:53     ` Robin Murphy
2022-04-28 21:09 ` [PATCH RFC 18/19] iommu/intel: Access/Dirty bit support for SL domains Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  9:03   ` Tian, Kevin
2022-04-29  9:03     ` Tian, Kevin
2022-04-29 11:20     ` Joao Martins
2022-04-29 11:20       ` Joao Martins
2022-04-30  6:12   ` Baolu Lu
2022-04-30  6:12     ` Baolu Lu
2022-05-02 12:24     ` Joao Martins
2022-05-02 12:24       ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 19/19] iommu/intel: Add unmap_read_dirty() support Joao Martins
2022-04-28 21:09   ` Joao Martins
2022-04-29  5:45 ` [PATCH RFC 00/19] IOMMUFD Dirty Tracking Tian, Kevin
2022-04-29  5:45   ` Tian, Kevin
2022-04-29 10:27   ` Joao Martins
2022-04-29 10:27     ` Joao Martins
2022-04-29 12:38     ` Jason Gunthorpe
2022-04-29 12:38       ` Jason Gunthorpe via iommu
2022-04-29 15:20       ` Joao Martins
2022-04-29 15:20         ` Joao Martins
2022-05-05  7:40       ` Tian, Kevin
2022-05-05  7:40         ` Tian, Kevin
2022-05-05 14:07         ` Jason Gunthorpe
2022-05-05 14:07           ` Jason Gunthorpe via iommu
2022-05-06  3:51           ` Tian, Kevin
2022-05-06  3:51             ` Tian, Kevin
2022-05-06 11:46             ` Jason Gunthorpe
2022-05-06 11:46               ` Jason Gunthorpe via iommu
2022-05-10  1:38               ` Tian, Kevin
2022-05-10  1:38                 ` Tian, Kevin
2022-05-10 11:50                 ` Joao Martins
2022-05-10 11:50                   ` Joao Martins
2022-05-11  1:17                   ` Tian, Kevin
2022-05-11  1:17                     ` Tian, Kevin
2022-05-10 13:46                 ` Jason Gunthorpe via iommu
2022-05-10 13:46                   ` Jason Gunthorpe
2022-05-11  1:10                   ` Tian, Kevin
2022-05-11  1:10                     ` Tian, Kevin
2022-07-12 18:34                     ` Joao Martins
2022-07-21 14:24                       ` Jason Gunthorpe
2022-05-02 18:11   ` Alex Williamson
2022-05-02 18:11     ` Alex Williamson
2022-05-02 18:52     ` Jason Gunthorpe
2022-05-02 18:52       ` Jason Gunthorpe via iommu
2022-05-03 10:48       ` Joao Martins
2022-05-03 10:48         ` Joao Martins
2022-05-05  7:42       ` Tian, Kevin
2022-05-05  7:42         ` Tian, Kevin
2022-05-05 10:06         ` Joao Martins
2022-05-05 10:06           ` Joao Martins
2022-05-05 11:03           ` Tian, Kevin
2022-05-05 11:03             ` Tian, Kevin
2022-05-05 11:50             ` Joao Martins
2022-05-05 11:50               ` Joao Martins
2022-05-06  3:14               ` Tian, Kevin
2022-05-06  3:14                 ` Tian, Kevin
2022-05-05 13:55             ` Jason Gunthorpe
2022-05-05 13:55               ` Jason Gunthorpe via iommu
2022-05-06  3:17               ` Tian, Kevin
2022-05-06  3:17                 ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d369e58-8ac0-f263-7b94-fe73917782e1@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=yishaih@nvidia.com \
    --cc=zhukeqian1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.