* [RFC PATCH 1/3] linux-headers: update against 5.12-rc2 and "vfio log clear" series
2021-03-10 9:41 [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
@ 2021-03-10 9:41 ` Kunkun Jiang
2021-03-10 9:41 ` [RFC PATCH 2/3] vfio: Maintain DMA mapping range for the container Kunkun Jiang
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-10 9:41 UTC (permalink / raw)
To: Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
From: Zenghui Yu <yuzenghui@huawei.com>
The new capability VFIO_DIRTY_LOG_MANUAL_CLEAR and the new ioctl
VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP have been introduced in
the kernel, update the header to add them.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
---
| 55 +++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
--git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 609099e455..9836c5442f 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -46,6 +46,20 @@
*/
#define VFIO_NOIOMMU_IOMMU 8
+/* Supports VFIO_DMA_UNMAP_FLAG_ALL */
+#define VFIO_UNMAP_ALL 9
+
+/* Supports the vaddr flag for DMA map and unmap */
+#define VFIO_UPDATE_VADDR 10
+
+/*
+ * The vfio_iommu driver may support user clears dirty log manually, which means
+ * dirty log is not cleared automatically after dirty log is copied to userspace,
+ * it's user's duty to clear dirty log. Note: when user queries this extension
+ * and vfio_iommu driver supports it, then it is enabled.
+ */
+#define VFIO_DIRTY_LOG_MANUAL_CLEAR 11
+
/*
* The IOCTL interface is designed for extensibility by embedding the
* structure length (argsz) and flags into structures passed between
@@ -1074,12 +1088,22 @@ struct vfio_iommu_type1_info_dma_avail {
*
* Map process virtual addresses to IO virtual addresses using the
* provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * If flags & VFIO_DMA_MAP_FLAG_VADDR, update the base vaddr for iova, and
+ * unblock translation of host virtual addresses in the iova range. The vaddr
+ * must have previously been invalidated with VFIO_DMA_UNMAP_FLAG_VADDR. To
+ * maintain memory consistency within the user application, the updated vaddr
+ * must address the same memory object as originally mapped. Failure to do so
+ * will result in user memory corruption and/or device misbehavior. iova and
+ * size must match those in the original MAP_DMA call. Protection is not
+ * changed, and the READ & WRITE flags must be 0.
*/
struct vfio_iommu_type1_dma_map {
__u32 argsz;
__u32 flags;
#define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
#define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
+#define VFIO_DMA_MAP_FLAG_VADDR (1 << 2)
__u64 vaddr; /* Process virtual address */
__u64 iova; /* IO virtual address */
__u64 size; /* Size of mapping (bytes) */
@@ -1102,6 +1126,7 @@ struct vfio_bitmap {
* field. No guarantee is made to the user that arbitrary unmaps of iova
* or size different from those used in the original mapping call will
* succeed.
+ *
* VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP should be set to get the dirty bitmap
* before unmapping IO virtual addresses. When this flag is set, the user must
* provide a struct vfio_bitmap in data[]. User must provide zero-allocated
@@ -1111,11 +1136,21 @@ struct vfio_bitmap {
* indicates that the page at that offset from iova is dirty. A Bitmap of the
* pages in the range of unmapped size is returned in the user-provided
* vfio_bitmap.data.
+ *
+ * If flags & VFIO_DMA_UNMAP_FLAG_ALL, unmap all addresses. iova and size
+ * must be 0. This cannot be combined with the get-dirty-bitmap flag.
+ *
+ * If flags & VFIO_DMA_UNMAP_FLAG_VADDR, do not unmap, but invalidate host
+ * virtual addresses in the iova range. Tasks that attempt to translate an
+ * iova's vaddr will block. DMA to already-mapped pages continues. This
+ * cannot be combined with the get-dirty-bitmap flag.
*/
struct vfio_iommu_type1_dma_unmap {
__u32 argsz;
__u32 flags;
#define VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP (1 << 0)
+#define VFIO_DMA_UNMAP_FLAG_ALL (1 << 1)
+#define VFIO_DMA_UNMAP_FLAG_VADDR (1 << 2)
__u64 iova; /* IO virtual address */
__u64 size; /* Size of mapping (bytes) */
__u8 data[];
@@ -1161,7 +1196,24 @@ struct vfio_iommu_type1_dma_unmap {
* actual bitmap. If dirty pages logging is not enabled, an error will be
* returned.
*
- * Only one of the flags _START, _STOP and _GET may be specified at a time.
+ * Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP flag set,
+ * instructs the IOMMU driver to clear the dirty status of pages in a bitmap
+ * for IOMMU container for a given IOVA range. The user must specify the IOVA
+ * range, the bitmap and the pgsize through the structure
+ * vfio_iommu_type1_dirty_bitmap_get in the data[] portion. This interface
+ * supports clearing a bitmap of the smallest supported pgsize only and can be
+ * modified in future to clear a bitmap of any specified supported pgsize. The
+ * user must provide a memory area for the bitmap memory and specify its size
+ * in bitmap.size. One bit is used to represent one page consecutively starting
+ * from iova offset. The user should provide page size in bitmap.pgsize field.
+ * A bit set in the bitmap indicates that the page at that offset from iova is
+ * cleared the dirty status, and dirty tracking is re-enabled for that page. The
+ * caller must set argsz to a value including the size of structure
+ * vfio_iommu_dirty_bitmap_get, but excluing the size of the actual bitmap. If
+ * dirty pages logging is not enabled, an error will be returned.
+ *
+ * Only one of the flags _START, _STOP, _GET and _CLEAR may be specified at a
+ * time.
*
*/
struct vfio_iommu_type1_dirty_bitmap {
@@ -1170,6 +1222,7 @@ struct vfio_iommu_type1_dirty_bitmap {
#define VFIO_IOMMU_DIRTY_PAGES_FLAG_START (1 << 0)
#define VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP (1 << 1)
#define VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP (1 << 2)
+#define VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP (1 << 3)
__u8 data[];
};
--
2.23.0
^ permalink raw reply related [flat|nested] 14+ messages in thread* [RFC PATCH 2/3] vfio: Maintain DMA mapping range for the container
2021-03-10 9:41 [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
2021-03-10 9:41 ` [RFC PATCH 1/3] linux-headers: update against 5.12-rc2 and "vfio log clear" series Kunkun Jiang
@ 2021-03-10 9:41 ` Kunkun Jiang
2021-03-10 9:41 ` [RFC PATCH 3/3] vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP Kunkun Jiang
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-10 9:41 UTC (permalink / raw)
To: Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
From: Zenghui Yu <yuzenghui@huawei.com>
When synchronizing dirty bitmap from kernel VFIO we do it in a
per-iova-range fashion and we allocate the userspace bitmap for each of the
ioctl. This patch introduces `struct VFIODMARange` to describe a range of
the given DMA mapping with respect to a VFIO_IOMMU_MAP_DMA operation, and
make the bitmap cache of this range be persistent so that we don't need to
g_try_malloc0() every time. Note that the new structure is almost a copy of
`struct vfio_iommu_type1_dma_map` but only internally used by QEMU.
More importantly, the cached per-iova-range dirty bitmap will be further
used when we want to add support for the CLEAR_BITMAP and this cached
bitmap will be used to guarantee we don't clear any unknown dirty bits
otherwise that can be a severe data loss issue for migration code.
It's pretty intuitive to maintain a bitmap per container since we perform
log_sync at this granule. But I don't know how to deal with things like
memory hot-{un}plug, sparse DMA mappings, etc. Suggestions welcome.
* yet something to-do:
- can't work with guest viommu
- no locks
- etc
[ The idea and even the commit message are largely inherited from kvm side.
See commit 9f4bf4baa8b820c7930e23c9566c9493db7e1d25. ]
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jinagkunkun@huawei.com>
---
hw/vfio/common.c | 62 +++++++++++++++++++++++++++++++----
include/hw/vfio/vfio-common.h | 9 +++++
2 files changed, 65 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index c0ff20f0a2..e7cb0e2b23 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -426,6 +426,29 @@ unmap_exit:
return ret;
}
+static VFIODMARange *vfio_lookup_match_range(VFIOContainer *container,
+ hwaddr start_addr, hwaddr size)
+{
+ VFIODMARange *qrange;
+
+ QLIST_FOREACH(qrange, &container->dma_list, next) {
+ if (qrange->iova == start_addr && qrange->size == size) {
+ return qrange;
+ }
+ }
+ return NULL;
+}
+
+static void vfio_dma_range_init_dirty_bitmap(VFIODMARange *qrange)
+{
+ uint64_t pages, size;
+
+ pages = REAL_HOST_PAGE_ALIGN(qrange->size) / qemu_real_host_page_size;
+ size = ROUND_UP(pages, sizeof(__u64) * BITS_PER_BYTE) / BITS_PER_BYTE;
+
+ qrange->bitmap = g_malloc0(size);
+}
+
/*
* DMA - Mapping and unmapping for the "type1" IOMMU interface used on x86
*/
@@ -439,12 +462,29 @@ static int vfio_dma_unmap(VFIOContainer *container,
.iova = iova,
.size = size,
};
+ VFIODMARange *qrange;
if (iotlb && container->dirty_pages_supported &&
vfio_devices_all_running_and_saving(container)) {
return vfio_dma_unmap_bitmap(container, iova, size, iotlb);
}
+ /*
+ * unregister the DMA range
+ *
+ * It seems that the memory layer will give us the same section as the one
+ * used in region_add(). Otherwise it'll be complicated to manipulate the
+ * bitmap across region_{add,del}. Is there any guarantee?
+ *
+ * But there is really not such a restriction on the kernel interface
+ * (VFIO_IOMMU_DIRTY_PAGES_FLAG_{UN}MAP_DMA, etc).
+ */
+ qrange = vfio_lookup_match_range(container, iova, size);
+ assert(qrange);
+ g_free(qrange->bitmap);
+ QLIST_REMOVE(qrange, next);
+ g_free(qrange);
+
while (ioctl(container->fd, VFIO_IOMMU_UNMAP_DMA, &unmap)) {
/*
* The type1 backend has an off-by-one bug in the kernel (71a7d3d78e3c
@@ -481,6 +521,14 @@ static int vfio_dma_map(VFIOContainer *container, hwaddr iova,
.iova = iova,
.size = size,
};
+ VFIODMARange *qrange;
+
+ qrange = g_malloc0(sizeof(*qrange));
+ qrange->iova = iova;
+ qrange->size = size;
+ QLIST_INSERT_HEAD(&container->dma_list, qrange, next);
+ /* XXX allocate the dirty bitmap on demand */
+ vfio_dma_range_init_dirty_bitmap(qrange);
if (!readonly) {
map.flags |= VFIO_DMA_MAP_FLAG_WRITE;
@@ -992,9 +1040,14 @@ static int vfio_get_dirty_bitmap(VFIOContainer *container, uint64_t iova,
{
struct vfio_iommu_type1_dirty_bitmap *dbitmap;
struct vfio_iommu_type1_dirty_bitmap_get *range;
+ VFIODMARange *qrange;
uint64_t pages;
int ret;
+ qrange = vfio_lookup_match_range(container, iova, size);
+ /* the same as vfio_dma_unmap() */
+ assert(qrange);
+
dbitmap = g_malloc0(sizeof(*dbitmap) + sizeof(*range));
dbitmap->argsz = sizeof(*dbitmap) + sizeof(*range);
@@ -1013,11 +1066,8 @@ static int vfio_get_dirty_bitmap(VFIOContainer *container, uint64_t iova,
pages = REAL_HOST_PAGE_ALIGN(range->size) / qemu_real_host_page_size;
range->bitmap.size = ROUND_UP(pages, sizeof(__u64) * BITS_PER_BYTE) /
BITS_PER_BYTE;
- range->bitmap.data = g_try_malloc0(range->bitmap.size);
- if (!range->bitmap.data) {
- ret = -ENOMEM;
- goto err_out;
- }
+
+ range->bitmap.data = (__u64 *)qrange->bitmap;
ret = ioctl(container->fd, VFIO_IOMMU_DIRTY_PAGES, dbitmap);
if (ret) {
@@ -1033,7 +1083,6 @@ static int vfio_get_dirty_bitmap(VFIOContainer *container, uint64_t iova,
trace_vfio_get_dirty_bitmap(container->fd, range->iova, range->size,
range->bitmap.size, ram_addr);
err_out:
- g_free(range->bitmap.data);
g_free(dbitmap);
return ret;
@@ -1737,6 +1786,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
container->dirty_pages_supported = false;
QLIST_INIT(&container->giommu_list);
QLIST_INIT(&container->hostwin_list);
+ QLIST_INIT(&container->dma_list);
ret = vfio_init_container(container, group->fd, errp);
if (ret) {
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index 6141162d7a..bd6eca9332 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -76,6 +76,14 @@ typedef struct VFIOAddressSpace {
struct VFIOGroup;
+typedef struct VFIODMARange {
+ QLIST_ENTRY(VFIODMARange) next;
+ hwaddr iova;
+ size_t size;
+ void *vaddr; /* unused */
+ unsigned long *bitmap; /* dirty bitmap cache for this range */
+} VFIODMARange;
+
typedef struct VFIOContainer {
VFIOAddressSpace *space;
int fd; /* /dev/vfio/vfio, empowered by the attached groups */
@@ -91,6 +99,7 @@ typedef struct VFIOContainer {
QLIST_HEAD(, VFIOGuestIOMMU) giommu_list;
QLIST_HEAD(, VFIOHostDMAWindow) hostwin_list;
QLIST_HEAD(, VFIOGroup) group_list;
+ QLIST_HEAD(, VFIODMARange) dma_list;
QLIST_ENTRY(VFIOContainer) next;
} VFIOContainer;
--
2.23.0
^ permalink raw reply related [flat|nested] 14+ messages in thread* [RFC PATCH 3/3] vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP
2021-03-10 9:41 [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
2021-03-10 9:41 ` [RFC PATCH 1/3] linux-headers: update against 5.12-rc2 and "vfio log clear" series Kunkun Jiang
2021-03-10 9:41 ` [RFC PATCH 2/3] vfio: Maintain DMA mapping range for the container Kunkun Jiang
@ 2021-03-10 9:41 ` Kunkun Jiang
2021-03-18 6:22 ` [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
2021-03-18 6:28 ` Tian, Kevin
4 siblings, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-10 9:41 UTC (permalink / raw)
To: Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
From: Zenghui Yu <yuzenghui@huawei.com>
The new capability VFIO_DIRTY_LOG_MANUAL_CLEAR and the new ioctl
VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP have been introduced in
the kernel, tweak the userspace side to use them.
Check if the kernel supports VFIO_DIRTY_LOG_MANUAL_CLEAR and
provide the log_clear() hook for vfio_memory_listener. If the
kernel supports it, deliever the clear message to kernel.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
---
hw/vfio/common.c | 145 +++++++++++++++++++++++++++++++++-
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index e7cb0e2b23..713515b86a 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1182,10 +1182,146 @@ static void vfio_listener_log_sync(MemoryListener *listener,
}
}
+/*
+ * I'm not sure if there's any alignment requirement for the CLEAR_BITMAP
+ * ioctl. But copy from kvm side and align {start, size} with 64 pages.
+ *
+ * I think the code can be simplified a lot if no alignment requirement.
+ */
+#define VFIO_CLEAR_LOG_SHIFT 6
+#define VFIO_CLEAR_LOG_ALIGN (qemu_real_host_page_size << VFIO_CLEAR_LOG_SHIFT)
+#define VFIO_CLEAR_LOG_MASK (-VFIO_CLEAR_LOG_ALIGN)
+
+static int vfio_log_clear_one_range(VFIOContainer *container,
+ VFIODMARange *qrange, uint64_t start, uint64_t size)
+{
+ struct vfio_iommu_type1_dirty_bitmap *dbitmap;
+ struct vfio_iommu_type1_dirty_bitmap_get *range;
+
+ dbitmap = g_malloc0(sizeof(*dbitmap) + sizeof(*range));
+
+ dbitmap->argsz = sizeof(*dbitmap) + sizeof(*range);
+ dbitmap->flags = VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP;
+ range = (struct vfio_iommu_type1_dirty_bitmap_get *)&dbitmap->data;
+
+ /*
+ * Now let's deal with the actual bitmap, which is almost the same
+ * as the kvm side.
+ */
+ uint64_t end, bmap_start, start_delta, bmap_npages;
+ unsigned long *bmap_clear = NULL, psize = qemu_real_host_page_size;
+ int ret;
+
+ bmap_start = start & VFIO_CLEAR_LOG_MASK;
+ start_delta = start - bmap_start;
+ bmap_start /= psize;
+
+ bmap_npages = DIV_ROUND_UP(size + start_delta, VFIO_CLEAR_LOG_ALIGN)
+ << VFIO_CLEAR_LOG_SHIFT;
+ end = qrange->size / psize;
+ if (bmap_npages > end - bmap_start) {
+ bmap_npages = end - bmap_start;
+ }
+ start_delta /= psize;
+
+ if (start_delta) {
+ bmap_clear = bitmap_new(bmap_npages);
+ bitmap_copy_with_src_offset(bmap_clear, qrange->bitmap,
+ bmap_start, start_delta + size / psize);
+ bitmap_clear(bmap_clear, 0, start_delta);
+ range->bitmap.data = (__u64 *)bmap_clear;
+ } else {
+ range->bitmap.data = (__u64 *)(qrange->bitmap + BIT_WORD(bmap_start));
+ }
+
+ range->iova = qrange->iova + bmap_start * psize;
+ range->size = bmap_npages * psize;
+ range->bitmap.size = ROUND_UP(bmap_npages, sizeof(__u64) * BITS_PER_BYTE) /
+ BITS_PER_BYTE;
+ range->bitmap.pgsize = qemu_real_host_page_size;
+
+ ret = ioctl(container->fd, VFIO_IOMMU_DIRTY_PAGES, dbitmap);
+ if (ret) {
+ error_report("Failed to clear dirty log for iova: 0x%"PRIx64
+ " size: 0x%"PRIx64" err: %d", (uint64_t)range->iova,
+ (uint64_t)range->size, errno);
+ goto err_out;
+ }
+
+ bitmap_clear(qrange->bitmap, bmap_start + start_delta, size / psize);
+err_out:
+ g_free(bmap_clear);
+ g_free(dbitmap);
+ return 0;
+}
+
+static int vfio_physical_log_clear(VFIOContainer *container,
+ MemoryRegionSection *section)
+{
+ uint64_t start, size, offset, count;
+ VFIODMARange *qrange;
+ int ret = 0;
+
+ if (!container->dirty_log_manual_clear) {
+ /* No need to do explicit clear */
+ return ret;
+ }
+
+ start = section->offset_within_address_space;
+ size = int128_get64(section->size);
+
+ if (!size) {
+ return ret;
+ }
+
+ QLIST_FOREACH(qrange, &container->dma_list, next) {
+ /*
+ * Discard ranges that do not overlap the section (e.g., the
+ * Memory BAR regions of the device)
+ */
+ if (qrange->iova > start + size - 1 ||
+ start > qrange->iova + qrange->size - 1) {
+ continue;
+ }
+
+ if (start >= qrange->iova) {
+ /* The range starts before section or is aligned to it. */
+ offset = start - qrange->iova;
+ count = MIN(qrange->size - offset, size);
+ } else {
+ /* The range starts after section. */
+ offset = 0;
+ count = MIN(qrange->size, size - (qrange->iova - start));
+ }
+ ret = vfio_log_clear_one_range(container, qrange, offset, count);
+ if (ret < 0) {
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static void vfio_listener_log_clear(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ VFIOContainer *container = container_of(listener, VFIOContainer, listener);
+
+ if (vfio_listener_skipped_section(section) ||
+ !container->dirty_pages_supported) {
+ return;
+ }
+
+ if (vfio_devices_all_saving(container)) {
+ vfio_physical_log_clear(container, section);
+ }
+}
+
static const MemoryListener vfio_memory_listener = {
.region_add = vfio_listener_region_add,
.region_del = vfio_listener_region_del,
.log_sync = vfio_listener_log_sync,
+ .log_clear = vfio_listener_log_clear,
};
static void vfio_listener_release(VFIOContainer *container)
@@ -1613,7 +1749,7 @@ static int vfio_get_iommu_type(VFIOContainer *container,
static int vfio_init_container(VFIOContainer *container, int group_fd,
Error **errp)
{
- int iommu_type, ret;
+ int iommu_type, dirty_log_manual_clear, ret;
iommu_type = vfio_get_iommu_type(container, errp);
if (iommu_type < 0) {
@@ -1642,6 +1778,13 @@ static int vfio_init_container(VFIOContainer *container, int group_fd,
}
container->iommu_type = iommu_type;
+
+ dirty_log_manual_clear = ioctl(container->fd, VFIO_CHECK_EXTENSION,
+ VFIO_DIRTY_LOG_MANUAL_CLEAR);
+ if (dirty_log_manual_clear) {
+ container->dirty_log_manual_clear = dirty_log_manual_clear;
+ }
+
return 0;
}
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index bd6eca9332..bcd6a0c440 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -93,6 +93,7 @@ typedef struct VFIOContainer {
Error *error;
bool initialized;
bool dirty_pages_supported;
+ bool dirty_log_manual_clear;
uint64_t dirty_pgsizes;
uint64_t max_dirty_bitmap_size;
unsigned long pgsizes;
--
2.23.0
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-10 9:41 [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
` (2 preceding siblings ...)
2021-03-10 9:41 ` [RFC PATCH 3/3] vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP Kunkun Jiang
@ 2021-03-18 6:22 ` Kunkun Jiang
2021-03-18 6:28 ` Tian, Kevin
4 siblings, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-18 6:22 UTC (permalink / raw)
To: Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, Tian, Kevin, open list:All patches CC here
Cc: Yan Zhao, Peter Xu, Eric Auger, shameerali.kolothum.thodi,
Zenghui Yu, wanghaibin.wang, Keqian Zhu
kindly ping,
Any comments and reviews are welcome.😁
Thanks,
Kunkun Jiang
On 2021/3/10 17:41, Kunkun Jiang wrote:
> Hi all,
>
> 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
>
> Thanks,
> Kunkun Jiang
>
> [1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-zhukeqian1@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f863
>
> Zenghui Yu (3):
> linux-headers: update against 5.12-rc2 and "vfio log clear" series
> vfio: Maintain DMA mapping range for the container
> vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP
>
> hw/vfio/common.c | 207 ++++++++++++++++++++++++++++++++--
> include/hw/vfio/vfio-common.h | 10 ++
> linux-headers/linux/vfio.h | 55 ++++++++-
> 3 files changed, 264 insertions(+), 8 deletions(-)
>
^ permalink raw reply [flat|nested] 14+ messages in thread* RE: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-10 9:41 [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
` (3 preceding siblings ...)
2021-03-18 6:22 ` [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log Kunkun Jiang
@ 2021-03-18 6:28 ` Tian, Kevin
2021-03-18 7:59 ` Kunkun Jiang
4 siblings, 1 reply; 14+ messages in thread
From: Tian, Kevin @ 2021-03-18 6:28 UTC (permalink / raw)
To: Kunkun Jiang, Alex Williamson, Michael S . Tsirkin,
Cornelia Huck, Paolo Bonzini, Kirti Wankhede,
Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: Peter Xu, Eric Auger, shameerali.kolothum.thodi, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
> From: Kunkun Jiang
> Sent: Wednesday, March 10, 2021 5:41 PM
>
> Hi all,
>
> 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.
Is there any performance data showing the benefit of this new method?
>
> 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
>
> Thanks,
> Kunkun Jiang
>
> [1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
> zhukeqian1@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f
> 863
>
> Zenghui Yu (3):
> linux-headers: update against 5.12-rc2 and "vfio log clear" series
> vfio: Maintain DMA mapping range for the container
> vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP
>
> hw/vfio/common.c | 207 ++++++++++++++++++++++++++++++++--
> include/hw/vfio/vfio-common.h | 10 ++
> linux-headers/linux/vfio.h | 55 ++++++++-
> 3 files changed, 264 insertions(+), 8 deletions(-)
>
> --
> 2.23.0
>
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 6:28 ` Tian, Kevin
@ 2021-03-18 7:59 ` Kunkun Jiang
2021-03-18 9:04 ` Tian, Kevin
0 siblings, 1 reply; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-18 7:59 UTC (permalink / raw)
To: Tian, Kevin, Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
Hi Kevin,
On 2021/3/18 14:28, Tian, Kevin wrote:
>> From: Kunkun Jiang
>> Sent: Wednesday, March 10, 2021 5:41 PM
>>
>> Hi all,
>>
>> 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.
> Is there any performance data showing the benefit of this new method?
>
Current dirty log tracking method for VFIO:
[1] All pages marked dirty if not all iommu_groups have pinned_scope
[2] pinned pages by various vendor drivers if all iommu_groups have
pinned scope
Both methods are coarse-grained and can not determine which pages are
really dirty. Each round may mark the pages that are not really dirty as
dirty
and send them to the destination. ( It might be better if the range of the
pinned_scope was smaller. ) This will result in a waste of resources.
HWDBM is short for Hardware Dirty Bit Management.
(e.g. smmuv3 HTTU, Hardware Translation Table Update)
About SMMU HTTU:
HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
state of the TTD (Translation Table Descriptor) by hardware.
With HTTU, stage1 TTD is classified into 3 types:
DBM bit AP[2](readonly bit)
1. writable_clean 1 1
2. writable_dirty 1 0
3. readonly 0 1
If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
writable_clean to writable_dirty. Then software can scan TTD to sync dirty
state into dirty bitmap. With this feature, we can track the dirty log of
DMA continuously and precisely.
The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
the KVM side. We add this new log_clear() interface only to split the old
log_sync() into two separated procedures:
- use log_sync() to collect the collection only, and,
- use log_clear() to clear the dirty bitmap.
If you're interested in this new method, you can take a look at our set of
patches.
[1]
https://lore.kernel.org/linux-iommu/20210310090614.26668-1-zhukeqian1@huawei.com/
Best regards,
Kunkun Jiang
>> 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
>>
>> Thanks,
>> Kunkun Jiang
>>
>> [1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
>> zhukeqian1@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f
>> 863
>>
>> Zenghui Yu (3):
>> linux-headers: update against 5.12-rc2 and "vfio log clear" series
>> vfio: Maintain DMA mapping range for the container
>> vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP
>>
>> hw/vfio/common.c | 207 ++++++++++++++++++++++++++++++++--
>> include/hw/vfio/vfio-common.h | 10 ++
>> linux-headers/linux/vfio.h | 55 ++++++++-
>> 3 files changed, 264 insertions(+), 8 deletions(-)
>>
>> --
>> 2.23.0
>>
>
> .
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 7:59 ` Kunkun Jiang
@ 2021-03-18 9:04 ` Tian, Kevin
2021-03-18 12:28 ` Kunkun Jiang
0 siblings, 1 reply; 14+ messages in thread
From: Tian, Kevin @ 2021-03-18 9:04 UTC (permalink / raw)
To: Kunkun Jiang, Alex Williamson, Michael S . Tsirkin,
Cornelia Huck, Paolo Bonzini, Kirti Wankhede,
Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
> From: Kunkun Jiang <jiangkunkun@huawei.com>
> Sent: Thursday, March 18, 2021 3:59 PM
>
> Hi Kevin,
>
> On 2021/3/18 14:28, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Wednesday, March 10, 2021 5:41 PM
> >>
> >> Hi all,
> >>
> >> 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.
> > Is there any performance data showing the benefit of this new method?
> >
> Current dirty log tracking method for VFIO:
> [1] All pages marked dirty if not all iommu_groups have pinned_scope
> [2] pinned pages by various vendor drivers if all iommu_groups have
> pinned scope
>
> Both methods are coarse-grained and can not determine which pages are
> really dirty. Each round may mark the pages that are not really dirty as
> dirty
> and send them to the destination. ( It might be better if the range of the
> pinned_scope was smaller. ) This will result in a waste of resources.
>
> HWDBM is short for Hardware Dirty Bit Management.
> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
>
> About SMMU HTTU:
> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
> state of the TTD (Translation Table Descriptor) by hardware.
>
> With HTTU, stage1 TTD is classified into 3 types:
> DBM bit AP[2](readonly bit)
> 1. writable_clean 1 1
> 2. writable_dirty 1 0
> 3. readonly 0 1
>
> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
> state into dirty bitmap. With this feature, we can track the dirty log of
> DMA continuously and precisely.
>
> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
> the KVM side. We add this new log_clear() interface only to split the old
> log_sync() into two separated procedures:
>
> - use log_sync() to collect the collection only, and,
> - use log_clear() to clear the dirty bitmap.
>
> If you're interested in this new method, you can take a look at our set of
> patches.
> [1]
> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
> zhukeqian1@huawei.com/
>
I know what you are doing. Intel is also working on VT-d dirty bit support
based on above link. What I'm curious is the actual performance gain
with this optimization. KVM doing that is one good reference, but IOMMU
has different characteristics (e.g. longer invalidation latency) compared to
CPU MMU. It's always good to understand what a so-called optimization
can actually optimize in a context different from where it's originally proved.😊
Thanks
Kevin
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 9:04 ` Tian, Kevin
@ 2021-03-18 12:28 ` Kunkun Jiang
2021-03-18 12:36 ` Tian, Kevin
0 siblings, 1 reply; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-18 12:28 UTC (permalink / raw)
To: Tian, Kevin, Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
Hi Kevin,
On 2021/3/18 17:04, Tian, Kevin wrote:
>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>> Sent: Thursday, March 18, 2021 3:59 PM
>>
>> Hi Kevin,
>>
>> On 2021/3/18 14:28, Tian, Kevin wrote:
>>>> From: Kunkun Jiang
>>>> Sent: Wednesday, March 10, 2021 5:41 PM
>>>>
>>>> Hi all,
>>>>
>>>> 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.
>>> Is there any performance data showing the benefit of this new method?
>>>
>> Current dirty log tracking method for VFIO:
>> [1] All pages marked dirty if not all iommu_groups have pinned_scope
>> [2] pinned pages by various vendor drivers if all iommu_groups have
>> pinned scope
>>
>> Both methods are coarse-grained and can not determine which pages are
>> really dirty. Each round may mark the pages that are not really dirty as
>> dirty
>> and send them to the destination. ( It might be better if the range of the
>> pinned_scope was smaller. ) This will result in a waste of resources.
>>
>> HWDBM is short for Hardware Dirty Bit Management.
>> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
>>
>> About SMMU HTTU:
>> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
>> state of the TTD (Translation Table Descriptor) by hardware.
>>
>> With HTTU, stage1 TTD is classified into 3 types:
>> DBM bit AP[2](readonly bit)
>> 1. writable_clean 1 1
>> 2. writable_dirty 1 0
>> 3. readonly 0 1
>>
>> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
>> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
>> state into dirty bitmap. With this feature, we can track the dirty log of
>> DMA continuously and precisely.
>>
>> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
>> the KVM side. We add this new log_clear() interface only to split the old
>> log_sync() into two separated procedures:
>>
>> - use log_sync() to collect the collection only, and,
>> - use log_clear() to clear the dirty bitmap.
>>
>> If you're interested in this new method, you can take a look at our set of
>> patches.
>> [1]
>> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
>> zhukeqian1@huawei.com/
>>
> I know what you are doing. Intel is also working on VT-d dirty bit support
> based on above link. What I'm curious is the actual performance gain
> with this optimization. KVM doing that is one good reference, but IOMMU
> has different characteristics (e.g. longer invalidation latency) compared to
> CPU MMU. It's always good to understand what a so-called optimization
> can actually optimize in a context different from where it's originally proved.😊
>
> Thanks
> Kevin
My understanding is that this is a new method, which is quite different
from the
previous two. So can you explain in more detail what performance data
you want?😁
Thanks,
Kunkun Jiang
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 12:28 ` Kunkun Jiang
@ 2021-03-18 12:36 ` Tian, Kevin
2021-03-18 13:14 ` Kunkun Jiang
2021-03-23 2:48 ` Kunkun Jiang
0 siblings, 2 replies; 14+ messages in thread
From: Tian, Kevin @ 2021-03-18 12:36 UTC (permalink / raw)
To: Kunkun Jiang, Alex Williamson, Michael S . Tsirkin,
Cornelia Huck, Paolo Bonzini, Kirti Wankhede,
Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: shameerali.kolothum.thodi, Eric Auger, Peter Xu, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
> From: Kunkun Jiang <jiangkunkun@huawei.com>
> Sent: Thursday, March 18, 2021 8:29 PM
>
> Hi Kevin,
>
> On 2021/3/18 17:04, Tian, Kevin wrote:
> >> From: Kunkun Jiang <jiangkunkun@huawei.com>
> >> Sent: Thursday, March 18, 2021 3:59 PM
> >>
> >> Hi Kevin,
> >>
> >> On 2021/3/18 14:28, Tian, Kevin wrote:
> >>>> From: Kunkun Jiang
> >>>> Sent: Wednesday, March 10, 2021 5:41 PM
> >>>>
> >>>> Hi all,
> >>>>
> >>>> 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.
> >>> Is there any performance data showing the benefit of this new method?
> >>>
> >> Current dirty log tracking method for VFIO:
> >> [1] All pages marked dirty if not all iommu_groups have pinned_scope
> >> [2] pinned pages by various vendor drivers if all iommu_groups have
> >> pinned scope
> >>
> >> Both methods are coarse-grained and can not determine which pages are
> >> really dirty. Each round may mark the pages that are not really dirty as
> >> dirty
> >> and send them to the destination. ( It might be better if the range of the
> >> pinned_scope was smaller. ) This will result in a waste of resources.
> >>
> >> HWDBM is short for Hardware Dirty Bit Management.
> >> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
> >>
> >> About SMMU HTTU:
> >> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
> >> state of the TTD (Translation Table Descriptor) by hardware.
> >>
> >> With HTTU, stage1 TTD is classified into 3 types:
> >> DBM bit AP[2](readonly bit)
> >> 1. writable_clean 1 1
> >> 2. writable_dirty 1 0
> >> 3. readonly 0 1
> >>
> >> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
> >> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
> >> state into dirty bitmap. With this feature, we can track the dirty log of
> >> DMA continuously and precisely.
> >>
> >> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
> >> the KVM side. We add this new log_clear() interface only to split the old
> >> log_sync() into two separated procedures:
> >>
> >> - use log_sync() to collect the collection only, and,
> >> - use log_clear() to clear the dirty bitmap.
> >>
> >> If you're interested in this new method, you can take a look at our set of
> >> patches.
> >> [1]
> >> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
> >> zhukeqian1@huawei.com/
> >>
> > I know what you are doing. Intel is also working on VT-d dirty bit support
> > based on above link. What I'm curious is the actual performance gain
> > with this optimization. KVM doing that is one good reference, but IOMMU
> > has different characteristics (e.g. longer invalidation latency) compared to
> > CPU MMU. It's always good to understand what a so-called optimization
> > can actually optimize in a context different from where it's originally
> proved.😊
> >
> > Thanks
> > Kevin
>
> My understanding is that this is a new method, which is quite different
> from the
> previous two. So can you explain in more detail what performance data
> you want?😁
>
> Thanks,
> Kunkun Jiang
When you have HTTU enabled, compare the migration efficiency with and
without this manual clear interface.
Thanks
Kevin
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 12:36 ` Tian, Kevin
@ 2021-03-18 13:14 ` Kunkun Jiang
2021-03-23 2:48 ` Kunkun Jiang
1 sibling, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-18 13:14 UTC (permalink / raw)
To: Tian, Kevin, Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: Peter Xu, Eric Auger, shameerali.kolothum.thodi, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
On 2021/3/18 20:36, Tian, Kevin wrote:
>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>> Sent: Thursday, March 18, 2021 8:29 PM
>>
>> Hi Kevin,
>>
>> On 2021/3/18 17:04, Tian, Kevin wrote:
>>>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>>>> Sent: Thursday, March 18, 2021 3:59 PM
>>>>
>>>> Hi Kevin,
>>>>
>>>> On 2021/3/18 14:28, Tian, Kevin wrote:
>>>>>> From: Kunkun Jiang
>>>>>> Sent: Wednesday, March 10, 2021 5:41 PM
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> 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.
>>>>> Is there any performance data showing the benefit of this new method?
>>>>>
>>>> Current dirty log tracking method for VFIO:
>>>> [1] All pages marked dirty if not all iommu_groups have pinned_scope
>>>> [2] pinned pages by various vendor drivers if all iommu_groups have
>>>> pinned scope
>>>>
>>>> Both methods are coarse-grained and can not determine which pages are
>>>> really dirty. Each round may mark the pages that are not really dirty as
>>>> dirty
>>>> and send them to the destination. ( It might be better if the range of the
>>>> pinned_scope was smaller. ) This will result in a waste of resources.
>>>>
>>>> HWDBM is short for Hardware Dirty Bit Management.
>>>> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
>>>>
>>>> About SMMU HTTU:
>>>> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
>>>> state of the TTD (Translation Table Descriptor) by hardware.
>>>>
>>>> With HTTU, stage1 TTD is classified into 3 types:
>>>> DBM bit AP[2](readonly bit)
>>>> 1. writable_clean 1 1
>>>> 2. writable_dirty 1 0
>>>> 3. readonly 0 1
>>>>
>>>> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
>>>> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
>>>> state into dirty bitmap. With this feature, we can track the dirty log of
>>>> DMA continuously and precisely.
>>>>
>>>> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
>>>> the KVM side. We add this new log_clear() interface only to split the old
>>>> log_sync() into two separated procedures:
>>>>
>>>> - use log_sync() to collect the collection only, and,
>>>> - use log_clear() to clear the dirty bitmap.
>>>>
>>>> If you're interested in this new method, you can take a look at our set of
>>>> patches.
>>>> [1]
>>>> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
>>>> zhukeqian1@huawei.com/
>>>>
>>> I know what you are doing. Intel is also working on VT-d dirty bit support
>>> based on above link. What I'm curious is the actual performance gain
>>> with this optimization. KVM doing that is one good reference, but IOMMU
>>> has different characteristics (e.g. longer invalidation latency) compared to
>>> CPU MMU. It's always good to understand what a so-called optimization
>>> can actually optimize in a context different from where it's originally
>> proved.😊
>>> Thanks
>>> Kevin
>> My understanding is that this is a new method, which is quite different
>> from the
>> previous two. So can you explain in more detail what performance data
>> you want?😁
>>
>> Thanks,
>> Kunkun Jiang
> When you have HTTU enabled, compare the migration efficiency with and
> without this manual clear interface.
>
> Thanks
> Kevin
Oh, I see. From a theoretical analysis, this manual clear interface will be
effective. I will perform some tests on it and send out the results.
Thanks,
Kunkun Jiang
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log
2021-03-18 12:36 ` Tian, Kevin
2021-03-18 13:14 ` Kunkun Jiang
@ 2021-03-23 2:48 ` Kunkun Jiang
1 sibling, 0 replies; 14+ messages in thread
From: Kunkun Jiang @ 2021-03-23 2:48 UTC (permalink / raw)
To: Tian, Kevin, Alex Williamson, Michael S . Tsirkin, Cornelia Huck,
Paolo Bonzini, Kirti Wankhede, Daniel P . Berrangé,
Tarun Gupta, open list:All patches CC here
Cc: Peter Xu, Eric Auger, shameerali.kolothum.thodi, Zenghui Yu,
wanghaibin.wang, Keqian Zhu
On 2021/3/18 20:36, Tian, Kevin wrote:
>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>> Sent: Thursday, March 18, 2021 8:29 PM
>>
>> Hi Kevin,
>>
>> On 2021/3/18 17:04, Tian, Kevin wrote:
>>>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>>>> Sent: Thursday, March 18, 2021 3:59 PM
>>>>
>>>> Hi Kevin,
>>>>
>>>> On 2021/3/18 14:28, Tian, Kevin wrote:
>>>>>> From: Kunkun Jiang
>>>>>> Sent: Wednesday, March 10, 2021 5:41 PM
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> 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.
>>>>> Is there any performance data showing the benefit of this new method?
>>>>>
>>>> Current dirty log tracking method for VFIO:
>>>> [1] All pages marked dirty if not all iommu_groups have pinned_scope
>>>> [2] pinned pages by various vendor drivers if all iommu_groups have
>>>> pinned scope
>>>>
>>>> Both methods are coarse-grained and can not determine which pages are
>>>> really dirty. Each round may mark the pages that are not really dirty as
>>>> dirty
>>>> and send them to the destination. ( It might be better if the range of the
>>>> pinned_scope was smaller. ) This will result in a waste of resources.
>>>>
>>>> HWDBM is short for Hardware Dirty Bit Management.
>>>> (e.g. smmuv3 HTTU, Hardware Translation Table Update)
>>>>
>>>> About SMMU HTTU:
>>>> HTTU is a feature of ARM SMMUv3, it can update access flag or/and dirty
>>>> state of the TTD (Translation Table Descriptor) by hardware.
>>>>
>>>> With HTTU, stage1 TTD is classified into 3 types:
>>>> DBM bit AP[2](readonly bit)
>>>> 1. writable_clean 1 1
>>>> 2. writable_dirty 1 0
>>>> 3. readonly 0 1
>>>>
>>>> If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from
>>>> writable_clean to writable_dirty. Then software can scan TTD to sync dirty
>>>> state into dirty bitmap. With this feature, we can track the dirty log of
>>>> DMA continuously and precisely.
>>>>
>>>> The capability of VFIO_DIRTY_LOG_MANUAL_CLEAR is similar to that on
>>>> the KVM side. We add this new log_clear() interface only to split the old
>>>> log_sync() into two separated procedures:
>>>>
>>>> - use log_sync() to collect the collection only, and,
>>>> - use log_clear() to clear the dirty bitmap.
>>>>
>>>> If you're interested in this new method, you can take a look at our set of
>>>> patches.
>>>> [1]
>>>> https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
>>>> zhukeqian1@huawei.com/
>>>>
>>> I know what you are doing. Intel is also working on VT-d dirty bit support
>>> based on above link. What I'm curious is the actual performance gain
>>> with this optimization. KVM doing that is one good reference, but IOMMU
>>> has different characteristics (e.g. longer invalidation latency) compared to
>>> CPU MMU. It's always good to understand what a so-called optimization
>>> can actually optimize in a context different from where it's originally
>> proved.😊
>>> Thanks
>>> Kevin
>> My understanding is that this is a new method, which is quite different
>> from the
>> previous two. So can you explain in more detail what performance data
>> you want?😁
>>
>> Thanks,
>> Kunkun Jiang
> When you have HTTU enabled, compare the migration efficiency with and
> without this manual clear interface.
>
> Thanks
> Kevin
Hi Kevin,
Sorry for late reply.
I tested it on our FPGA in two scenarios.
[1] perform limited times of DMA on a fixed ram area
[2] perform infinite DMA on a fixed ram area
In scenario [1], we can clearly see that lesser data is being transmitted
with this manual clear interface. For example, a total of 10 DMA are
performed, the amount of transferred data is the sum of 6 times. This
depends on whether the device performs a DMA on the dirty ram
area between log_sync() and log_clear().
In scenario [2], with or without this manual clear interface, it doesn't
make a big difference. Every time we call log_sync(), the fixed ram
area is dirty.
So, in general scenarios, it can reduce the amount of transmitted data.
In addition, regarding the difference between MMU and IOMMU (e.g.
longer invalidation latency) you mentioned last time, I think it has no
effect on this manual clear interface. Currently, the way we invalidate
IOMMU TLB is iommu_flush_iotlb_all(). It takes lesser time than multiple,
range-based invalidation.
Thanks,
Kunkun Jiang
^ permalink raw reply [flat|nested] 14+ messages in thread