On 16 Oct 2026, at 6:37 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
!-------------------------------------------------------------------| CAUTION: External Email
|-------------------------------------------------------------------!
On Thu, Sep 17, 2026 at 06:20:29 +0000, Tejus GK wrote:
QEMU supports a migration parameter to determine whether zero-page checking should be performed and if yes, where it should be performed (i.e., in the main migration thread or multifd threads). Add support for this parameter in libvirt.
Signed-off-by: Tejus GK <tejus.gk@nutanix.com> --- include/libvirt/libvirt-domain.h | 11 +++++++++++ src/qemu/qemu_migration.c | 1 + src/qemu/qemu_migration_params.c | 8 ++++++++ src/qemu/qemu_migration_params.h | 1 + tools/virsh-domain.c | 13 +++++++++++++ 5 files changed, 34 insertions(+)
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 99208137c3..5a4875770b 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -1468,6 +1468,17 @@ typedef enum { */ # define VIR_MIGRATE_PARAM_TLS_DESTINATION "tls.destination"
+/** + * VIR_MIGRATE_PARAM_ZERO_PAGE_DETECTION: + * + * virDomainMigrate* params field: zero page detection method as + * VIR_TYPED_PARAM_STRING. Supported values are 'none', 'legacy', and + * 'multifd'. + * + * Since: 12.8.0 + */ +# define VIR_MIGRATE_PARAM_ZERO_PAGE_DETECTION "zero_page_detection" +
Historically zero page detection has always been performed and it was done in the main thread. Which is what is happening when this parameter is not set as QEMU defaults to "legacy". Given that the "multifd" value fallbacks to "legacy" if multifd migration is not enabled and that I can't think of a reason to disable the detection completely, I think should just always set this parameter to "multifd" when QEMU is new enough to support it.
That said, if for some reason we'd want to allow users to disable zero page detection, we should do it via a boolean parameter that would select between "none" and "multifd" as there's no reason for exposing "legacy"
Jirka
Hi Jiri, thank you for the review! I’ll respin this patch by changing the param to a boolean one instead, and send a V2 shortly. regards, tejus