>-----Original Message----- >From: Liu, Yi L <[email protected]> >Subject: Re: [PATCH v2 7/8] vfio/migration: Add migration blocker if VM >memory is too large to cause unmap_bitmap failure > >On 2025/10/17 16:22, Zhenzhong Duan wrote: >> 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 <[email protected]> >> Signed-off-by: Zhenzhong Duan <[email protected]> >> --- >> 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); > >Should use qemu_real_host_page_size() here?
hmm, I think it's host mmu page size which is not as accurate as the iommu page sizes? here we want the iommu ones. Thanks Zhenzhong
