| Message ID | 20210508093105.2558-1-jiangkunkun@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | vfio/migration: Support manual clear vfio dirty log | expand |
Hi all, Sorry for my carelessness. This is the v2 of this series. Thanks, Kunkun Jiang On 2021/5/8 17:31, Kunkun Jiang wrote: > In the past, we clear dirty log immediately after sync dirty log to > userspace. This may cause redundant dirty handling if userspace > handles dirty log iteratively: > > After vfio clears dirty log, new dirty log starts to generate. These > new dirty log will be reported to userspace even if they are generated > before userspace handles the same dirty page. > > Since a new dirty log tracking method for vfio based on iommu hwdbm[1] > has been introduced in the kernel and added a new capability named > VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant dirty > handling by supporting it. > > This series include patches as below: > Patch 1: > - updated the linux-headers/linux/vfio.h from kernel side > > Patch 2: > - introduced 'struct VFIODMARange' to describe a range of the given DMA > mapping and with respect to a VFIO_IOMMU_MAP_DMA operation > > Patch 3: > - implemented the operation to manual clear vfio dirty log, which can > eliminate some redundant dirty handling > > History: > v1 -> v2: > - Add a new ioctl VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP_NOCLEAR to get > vfio dirty log when support manual clear. > > Thanks, > Kunkun Jiang > > [1] > IOMMU part: https://lore.kernel.org/linux-iommu/20210507102211.8836-1-zhukeqian1@huawei.com/ > VFIO part: https://lore.kernel.org/kvm/20210507103608.39440-1-zhukeqian1@huawei.com/ > > Zenghui Yu (3): > linux-headers: update against 5.12 and "manual clear vfio dirty log" > series > vfio: Maintain DMA mapping range for the container > vfio/migration: Add support for manual clear vfio dirty log > > hw/vfio/common.c | 211 ++++++++++++++++++++++++++++++++-- > include/hw/vfio/vfio-common.h | 10 ++ > linux-headers/linux/vfio.h | 61 +++++++++- > 3 files changed, 273 insertions(+), 9 deletions(-) >
In the past, we clear dirty log immediately after sync dirty log to userspace. This may cause redundant dirty handling if userspace handles dirty log iteratively: After vfio clears dirty log, new dirty log starts to generate. These new dirty log will be reported to userspace even if they are generated before userspace handles the same dirty page. Since a new dirty log tracking method for vfio based on iommu hwdbm[1] has been introduced in the kernel and added a new capability named VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant dirty handling by supporting it. This series include patches as below: Patch 1: - updated the linux-headers/linux/vfio.h from kernel side Patch 2: - introduced 'struct VFIODMARange' to describe a range of the given DMA mapping and with respect to a VFIO_IOMMU_MAP_DMA operation Patch 3: - implemented the operation to manual clear vfio dirty log, which can eliminate some redundant dirty handling History: v1 -> v2: - Add a new ioctl VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP_NOCLEAR to get vfio dirty log when support manual clear. Thanks, Kunkun Jiang [1] IOMMU part: https://lore.kernel.org/linux-iommu/20210507102211.8836-1-zhukeqian1@huawei.com/ VFIO part: https://lore.kernel.org/kvm/20210507103608.39440-1-zhukeqian1@huawei.com/ Zenghui Yu (3): linux-headers: update against 5.12 and "manual clear vfio dirty log" series vfio: Maintain DMA mapping range for the container vfio/migration: Add support for manual clear vfio dirty log hw/vfio/common.c | 211 ++++++++++++++++++++++++++++++++-- include/hw/vfio/vfio-common.h | 10 ++ linux-headers/linux/vfio.h | 61 +++++++++- 3 files changed, 273 insertions(+), 9 deletions(-)