From: Zhenzhong Duan <zhenzhong.duan@intel.com>
To: qemu-devel@nongnu.org
Cc: alex.williamson@redhat.com, clg@redhat.com, mst@redhat.com,
jasowang@redhat.com, yi.l.liu@intel.com,
clement.mathieu--drif@eviden.com, eric.auger@redhat.com,
joao.m.martins@oracle.com, avihaih@nvidia.com,
xudong.hao@intel.com, giovanni.cabiddu@intel.com,
mark.gross@intel.com, arjan.van.de.ven@intel.com,
Zhenzhong Duan <zhenzhong.duan@intel.com>
Subject: [PATCH v2 7/8] vfio/migration: Add migration blocker if VM memory is too large to cause unmap_bitmap failure
Date: Fri, 17 Oct 2025 04:22:32 -0400 [thread overview]
Message-ID: <20251017082234.517827-8-zhenzhong.duan@intel.com> (raw)
In-Reply-To: <20251017082234.517827-1-zhenzhong.duan@intel.com>
With default config, kernel VFIO type1 driver limits dirty bitmap to 256MB
for unmap_bitmap ioctl so the maximum guest memory region is no more than
8TB size for the ioctl to succeed.
Be conservative here to limit total guest memory to 8TB or else add a
migration blocker. IOMMUFD backend doesn't have such limit, one can use
IOMMUFD backed device if there is a need to migration such large VM.
Suggested-by: Yi Liu <yi.l.liu@intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
---
hw/vfio/migration.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index 4c06e3db93..1106ca7857 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -16,6 +16,7 @@
#include <sys/ioctl.h>
#include "system/runstate.h"
+#include "hw/boards.h"
#include "hw/vfio/vfio-device.h"
#include "hw/vfio/vfio-migration.h"
#include "migration/misc.h"
@@ -1152,6 +1153,35 @@ static bool vfio_viommu_preset(VFIODevice *vbasedev)
return vbasedev->bcontainer->space->as != &address_space_memory;
}
+static bool vfio_dirty_tracking_exceed_limit(VFIODevice *vbasedev)
+{
+ VFIOContainer *bcontainer = vbasedev->bcontainer;
+ uint64_t max_size, page_size;
+
+ if (!object_dynamic_cast(OBJECT(bcontainer), TYPE_VFIO_IOMMU_LEGACY)) {
+ return false;
+ }
+
+ if (!bcontainer->dirty_pages_supported) {
+ return true;
+ }
+ /*
+ * VFIO type1 driver has a limitation of bitmap size on unmap_bitmap
+ * ioctl(), calculate the limit and compare with guest memory size to
+ * catch dirty tracking failure early.
+ *
+ * This limit is 8TB with default kernel and QEMU config, we are a bit
+ * conservative here as VM memory layout may be nonconsecutive or VM
+ * can run with vIOMMU enabled so the limitation could be relaxed. One
+ * can also switch to use IOMMUFD backend if there is a need to migrate
+ * large VM.
+ */
+ page_size = 1 << ctz64(bcontainer->dirty_pgsizes);
+ max_size = bcontainer->max_dirty_bitmap_size * BITS_PER_BYTE * page_size;
+
+ return current_machine->ram_size > max_size;
+}
+
/*
* Return true when either migration initialized or blocker registered.
* Currently only return false when adding blocker fails which will
@@ -1208,6 +1238,13 @@ bool vfio_migration_realize(VFIODevice *vbasedev, Error **errp)
goto add_blocker;
}
+ if (vfio_dirty_tracking_exceed_limit(vbasedev)) {
+ error_setg(&err, "%s: Migration is currently not supported with "
+ "large memory VM due to dirty tracking limitation in "
+ "VFIO type1 driver", vbasedev->name);
+ goto add_blocker;
+ }
+
trace_vfio_migration_realize(vbasedev->name);
return true;
--
2.47.1
next prev parent reply other threads:[~2025-10-17 8:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 8:22 [PATCH v2 0/8] vfio: relax the vIOMMU check Zhenzhong Duan
2025-10-17 8:22 ` [PATCH v2 1/8] vfio/iommufd: Add framework code to support getting dirty bitmap before unmap Zhenzhong Duan
2025-10-20 7:00 ` Cédric Le Goater
2025-10-20 12:44 ` Yi Liu
2025-10-17 8:22 ` [PATCH v2 2/8] vfio/iommufd: Query dirty bitmap before DMA unmap Zhenzhong Duan
2025-10-20 7:00 ` Cédric Le Goater
2025-10-20 8:14 ` Avihai Horon
2025-10-20 10:00 ` Duan, Zhenzhong
2025-10-20 12:45 ` Yi Liu
2025-10-20 13:04 ` Avihai Horon
2025-10-21 3:30 ` Yi Liu
2025-10-20 12:44 ` Yi Liu
2025-10-17 8:22 ` [PATCH v2 3/8] vfio/container-legacy: rename vfio_dma_unmap_bitmap() to vfio_legacy_dma_unmap_get_dirty_bitmap() Zhenzhong Duan
2025-10-20 7:00 ` Cédric Le Goater
2025-10-20 12:45 ` Yi Liu
2025-10-17 8:22 ` [PATCH v2 4/8] vfio: Add a backend_flag parameter to vfio_contianer_query_dirty_bitmap() Zhenzhong Duan
2025-10-20 7:01 ` Cédric Le Goater
2025-10-20 12:44 ` Yi Liu
2025-10-17 8:22 ` [PATCH v2 5/8] vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support Zhenzhong Duan
2025-10-20 7:01 ` Cédric Le Goater
2025-10-20 12:45 ` Yi Liu
2025-10-17 8:22 ` [PATCH v2 6/8] intel_iommu: Fix unmap_bitmap failure with legacy VFIO backend Zhenzhong Duan
2025-10-20 7:06 ` Cédric Le Goater
2025-10-20 7:38 ` Yi Liu
2025-10-20 8:03 ` Duan, Zhenzhong
2025-10-20 8:37 ` Yi Liu
2025-10-20 10:01 ` Duan, Zhenzhong
2025-10-17 8:22 ` Zhenzhong Duan [this message]
2025-10-20 8:39 ` [PATCH v2 7/8] vfio/migration: Add migration blocker if VM memory is too large to cause unmap_bitmap failure Cédric Le Goater
2025-10-20 10:07 ` Duan, Zhenzhong
2025-10-20 12:44 ` Yi Liu
2025-10-21 8:25 ` Duan, Zhenzhong
2025-10-17 8:22 ` [PATCH v2 8/8] vfio/migration: Allow live migration with vIOMMU without VFs using device dirty tracking Zhenzhong Duan
2025-10-20 12:46 ` Yi Liu
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=20251017082234.517827-8-zhenzhong.duan@intel.com \
--to=zhenzhong.duan@intel.com \
--cc=alex.williamson@redhat.com \
--cc=arjan.van.de.ven@intel.com \
--cc=avihaih@nvidia.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=clg@redhat.com \
--cc=eric.auger@redhat.com \
--cc=giovanni.cabiddu@intel.com \
--cc=jasowang@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=mark.gross@intel.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xudong.hao@intel.com \
--cc=yi.l.liu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).