From patchwork Mon Jun 20 11:01:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= X-Patchwork-Id: 12887328 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8EA5CC43334 for ; Mon, 20 Jun 2022 11:04:43 +0000 (UTC) Received: from localhost ([::1]:45816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3FD0-0005rE-5u for qemu-devel@archiver.kernel.org; Mon, 20 Jun 2022 07:04:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3FAf-0002m4-Ut for qemu-devel@nongnu.org; Mon, 20 Jun 2022 07:02:17 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:27522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3FAd-0007Tp-Jx for qemu-devel@nongnu.org; Mon, 20 Jun 2022 07:02:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655722934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=k7M9eG4ES0Tb9RcaMGRjXBPRle1hQce1Gzhgv+9UBsw=; b=F5i+/hXGEIFIbaEuRTepfx+i1PDhZZ6yqTM+z/8yv2uKbyLqjo0sxbSs+Kl8XMgo3KzXQU OMbV2TYs/g1KdolbI5ahmzMMMCWYBBWNz5H/8DAzZKIpuWh0d0rvH+iVpjpvrpJiUFGrM5 94TyWOcEkfHm/NQH9QW/yEvflDiktj8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-34-J26uDEXZPKiOmHUDixspUg-1; Mon, 20 Jun 2022 07:02:09 -0400 X-MC-Unique: J26uDEXZPKiOmHUDixspUg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4DC5A80B70E; Mon, 20 Jun 2022 11:02:09 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.33.36.144]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5EDDCC2810D; Mon, 20 Jun 2022 11:02:07 +0000 (UTC) From: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Juan Quintela , "Dr. David Alan Gilbert" , Stefan Hajnoczi , Hailiang Zhang , Fam Zheng , Hailiang Zhang Subject: [PATCH v2 00/21] migration: remove QEMUFileOps concept and assume use of QIOChannel Date: Mon, 20 Jun 2022 12:01:44 +0100 Message-Id: <20220620110205.1357829-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Quite a while ago now, the majority of QEMUFile implementations were switched over to use QIOChannel APIs, but a couple remained. The newish multifd code is directly using QIOChannel, only calling in to QEMUFile for the VMState transfer and for rate limiting purposes. This series finishes the job of converting QEMUFile to always have a QIOChannel as its backend, enabling a removal of QEMUFileOps. Most callers still need to use the QEMUFile APIs though, as that performs buffering of reads/writes. As a followup to this series, however, it would be practical to introduce a QIOChannelCache that layers on top of another QIOChannel to add buffering equivalent to what QEMUFile does, possibly with the rate limiting too. At that point QEMUFile would not really be doing much at all and could possibly go away entirely, leaving just the MigrationState object for global state tracking, managing one or more QIOChannel objects for the data transfer. I think this could simplify future evolution of migration code. I'm not likely to have time in the immediate future to work on such a followup though. Changed in v2: - Fix explanation of QIOChannelNull functionality - Improve commit message wrt renaming 'pos' field - Add patch to rename qemu_update_transfer method too - Avoid redundancy in qemu_file_total_transferred and qemu_file_total_transferred_fast docs - Address line length / trailing whitespace - Remove qemu_get_fd prototype at same time as QEMUFileGetFD typedef Daniel P. Berrangé (21): io: add a QIOChannelNull equivalent to /dev/null migration: switch to use QIOChannelNull for dummy channel migration: remove unreachble RDMA code in save_hook impl migration: rename rate limiting fields in QEMUFile migration: rename 'pos' field in QEMUFile to 'bytes_processed' migration: rename qemu_ftell to qemu_file_total_transferred migration: rename qemu_update_position to qemu_file_credit_transfer migration: rename qemu_file_update_transfer to qemu_file_acct_rate_limit migration: introduce a QIOChannel impl for BlockDriverState VMState migration: convert savevm to use QIOChannelBlock for VMState migration: stop passing 'opaque' parameter to QEMUFile hooks migration: hardcode assumption that QEMUFile is backed with QIOChannel migration: introduce new constructors for QEMUFile migration: remove unused QEMUFileGetFD typedef / qemu_get_fd method migration: remove the QEMUFileOps 'shut_down' callback migration: remove the QEMUFileOps 'set_blocking' callback migration: remove the QEMUFileOps 'close' callback migration: remove the QEMUFileOps 'get_buffer' callback migration: remove the QEMUFileOps 'writev_buffer' callback migration: remove the QEMUFileOps 'get_return_path' callback migration: remove the QEMUFileOps abstraction include/io/channel-null.h | 55 +++++++ io/channel-null.c | 237 ++++++++++++++++++++++++++++++ io/meson.build | 1 + io/trace-events | 3 + migration/block.c | 10 +- migration/channel-block.c | 195 ++++++++++++++++++++++++ migration/channel-block.h | 59 ++++++++ migration/channel.c | 4 +- migration/colo.c | 5 +- migration/meson.build | 2 +- migration/migration.c | 10 +- migration/multifd.c | 4 +- migration/qemu-file-channel.c | 194 ------------------------ migration/qemu-file-channel.h | 32 ---- migration/qemu-file.c | 193 +++++++++++++----------- migration/qemu-file.h | 125 +++++++--------- migration/ram.c | 8 +- migration/rdma.c | 144 +++++------------- migration/savevm.c | 55 ++----- migration/vmstate.c | 4 +- tests/unit/meson.build | 1 + tests/unit/test-io-channel-null.c | 95 ++++++++++++ tests/unit/test-vmstate.c | 5 +- 23 files changed, 879 insertions(+), 562 deletions(-) create mode 100644 include/io/channel-null.h create mode 100644 io/channel-null.c create mode 100644 migration/channel-block.c create mode 100644 migration/channel-block.h delete mode 100644 migration/qemu-file-channel.c delete mode 100644 migration/qemu-file-channel.h create mode 100644 tests/unit/test-io-channel-null.c