Re: [PATCH Kernel v24 4/8] vfio iommu: Add ioctl definition for dirty pages tracking

[Stefan Hajnoczi]

On Fri, May 29, 2020 at 02:00:50AM +0530, Kirti Wankhede wrote:
> + * Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP flag set
> + * returns the dirty pages bitmap for IOMMU container for a given IOVA range.
> + * The user must specify the IOVA range and the pgsize through the structure
> + * vfio_iommu_type1_dirty_bitmap_get in the data[] portion. This interface
> + * supports getting a bitmap of the smallest supported pgsize only and can be
> + * modified in future to get a bitmap of any specified supported pgsize. The
> + * user must provide a zeroed memory area for the bitmap memory and specify 
> its
> + * size in bitmap.size. One bit is used to represent one page consecutively

Does "user must provide a zeroed memory area" actually means "the vendor
driver sets bits for pages that are dirty and leaves bits unchanged for
pages that were not dirtied"? That is more flexible and different from
requiring userspace to zero memory.

For example, if userspace doesn't actually have to zero memory then it
can accumulate dirty pages from multiple devices by passing the same
bitmap buffers to multiple VFIO devices.

If that's the intention, then the documentation shouldn't say "must"
zero memory, because applications will need to violate that :). Instead
the documentation should describe the behavior (setting dirty bits,
leaving clean bits unmodified).

> +struct vfio_iommu_type1_dirty_bitmap_get {
> +     __u64              iova;        /* IO virtual address */
> +     __u64              size;        /* Size of iova range */
> +     struct vfio_bitmap bitmap;
> +};

Can the user application efficiently seek to the next dirty bit or does
this API force it to scan the entire iova space each time?

signature.asc
Description: PGP signature