From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAaOJ-0000Bg-FJ for qemu-devel@nongnu.org; Tue, 16 May 2017 07:11:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAaOI-00035D-DZ for qemu-devel@nongnu.org; Tue, 16 May 2017 07:11:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43056) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dAaOI-000324-52 for qemu-devel@nongnu.org; Tue, 16 May 2017 07:11:46 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC4314E4C6 for ; Tue, 16 May 2017 11:11:33 +0000 (UTC) From: Juan Quintela Date: Tue, 16 May 2017 13:11:18 +0200 Message-Id: <20170516111123.17692-1-quintela@redhat.com> Subject: [Qemu-devel] [PATCH v4 0/5] Remove old MigrationParams List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: dgilbert@redhat.com, lvivier@redhat.com, peterx@redhat.com, eblake@redhat.com, armbru@redhat.com changes from v3 - patch 1 included again. We have a 'block' capability and a 'block_incremental' parameter Make Dave happy: rename shared into incremental Make Eric and Markus happy: block: off -> no block migration, we don't care about block_incremental value block: on block_incremental: off -> no incremental block migration block: on block_incremental: on -> incremental block migration - Use visitors. You ask if there is not a better way than hand coding a boolean parser. QAPI people (a.k.a. Markus) answer to use a visitor. Once there, I used it also for integers, not only booleans. - Use -b/-i parameters. OK, I bit the bullet: You can't use capabilities/parameters and -b/-i: it gives you one error If you use -b/-i, capability parameter is cleanup after the migration ends (Who would have guessed that there are cases where we call migration_fd_error(), but not migration_fd_cleanup() I think this should make Peter and Markus and Dave happy. - Integrate migrate block compile time disabling Well, it conflicted left and right, so I fixed it Once there, I disable setting/getting block capability if it is disabled. Please review. [v3] - Patch 1 included in pull request - disable block_shared when we disable block_enable - enable block_enabled when we enable block_shared Please, review. [v2] - make migrate_block_set_* take a boolean - disable block migration in colo to maintain semantics. [v1] Upon a time there were MigrationParms (only used for block migration) and then MigrationParams used for everything else. This series: - create migration capabilities for block parameters - make the migrate command line parameters to use capabilities - remove MigrationParams completely Dr. David Alan Gilbert (1): block migration: Allow compile time disable Juan Quintela (4): hmp: Use visitor api for hmp_migrate_set_parameter() migration: Create block capability migration: Remove use of old MigrationParams migration: Remove old MigrationParams configure | 11 +++++ hmp.c | 23 +++++++-- include/migration/block.h | 24 +++++++++ include/migration/migration.h | 18 +++---- include/migration/vmstate.h | 1 - include/qemu/typedefs.h | 1 - include/sysemu/sysemu.h | 3 +- migration/Makefile.objs | 2 +- migration/block.c | 17 +------ migration/colo.c | 6 +-- migration/migration.c | 112 +++++++++++++++++++++++++++++++++++++++--- migration/savevm.c | 24 ++++----- qapi-schema.json | 14 ++++-- 13 files changed, 194 insertions(+), 62 deletions(-) -- 2.9.3