From nobody Mon Feb 9 12:09:54 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1565023229; cv=none; d=zoho.com; s=zohoarc; b=M24gR+MZYCsIy7EGsEYZy8JU4S172c/JLoce3Q2GRoSI2JxsGV/PHbu6/BNMGHo0DurB1Tz0Wra2ze5ss1WK5nlegUGAdAJQlgZXfeo1Pzd7v0zUHavIxpTYlhGQ40dxW5ZxU0d4MW+kaNjXV26agrtGk5mlambz+djDICKdcr8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1565023229; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=3uLLEThlWjRxq2vUfatS+RTB3Q1xSXuAqlPFWzQUhy4=; b=EGBwlZpMnWTc7kYHLevWElTw+xUL12DCHDzspfgNYVQCQutscVTs4CzzUkj+fxdrT2HcoMa0uog64HRtAibjk9edAYtMcWSd6tYKRZVH/VKrF6siVg3pLVMMMqUgb72+8fMKYOLt/Zhx1BJ4VYLLStMjlts/yhGjIOnpy+ieeTE= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1565023229692272.64940312085935; Mon, 5 Aug 2019 09:40:29 -0700 (PDT) Received: from localhost ([::1]:55974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hug28-0001qN-MG for importer@patchew.org; Mon, 05 Aug 2019 12:40:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37443) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hufzZ-0005eh-9F for qemu-devel@nongnu.org; Mon, 05 Aug 2019 12:37:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hufzY-0005pZ-99 for qemu-devel@nongnu.org; Mon, 05 Aug 2019 12:37:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35214) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hufzW-0005oV-6v; Mon, 05 Aug 2019 12:37:46 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 712F83002E27; Mon, 5 Aug 2019 16:37:45 +0000 (UTC) Received: from localhost (unknown [10.40.205.217]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 069205DC18; Mon, 5 Aug 2019 16:37:44 +0000 (UTC) From: Max Reitz To: qemu-block@nongnu.org Date: Mon, 5 Aug 2019 18:37:34 +0200 Message-Id: <20190805163740.23616-2-mreitz@redhat.com> In-Reply-To: <20190805163740.23616-1-mreitz@redhat.com> References: <20190805163740.23616-1-mreitz@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 05 Aug 2019 16:37:45 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/7] backup: Copy only dirty areas X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Peter Maydell , qemu-devel@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" The backup job must only copy areas that the copy_bitmap reports as dirty. This is always the case when using traditional non-offloading backup, because it copies each cluster separately. When offloading the copy operation, we sometimes copy more than one cluster at a time, but we only check whether the first one is dirty. Therefore, whenever copy offloading is possible, the backup job currently produces wrong output when the guest writes to an area of which an inner part has already been backed up, because that inner part will be re-copied. Fixes: 9ded4a0114968e98b41494fc035ba14f84cdf700 Signed-off-by: Max Reitz Reviewed-by: Vladimir Sementsov-Ogievskiy Message-id: 20190801173900.23851-2-mreitz@redhat.com Signed-off-by: Max Reitz --- block/backup.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/block/backup.c b/block/backup.c index 715e1d3be8..1ee271f9f1 100644 --- a/block/backup.c +++ b/block/backup.c @@ -202,22 +202,31 @@ static int coroutine_fn backup_do_cow(BackupBlockJob = *job, cow_request_begin(&cow_request, job, start, end); =20 while (start < end) { + int64_t dirty_end; + if (!hbitmap_get(job->copy_bitmap, start)) { trace_backup_do_cow_skip(job, start); start +=3D job->cluster_size; continue; /* already copied */ } =20 + dirty_end =3D hbitmap_next_zero(job->copy_bitmap, start, (end - st= art)); + if (dirty_end < 0) { + dirty_end =3D end; + } + trace_backup_do_cow_process(job, start); =20 if (job->use_copy_range) { - ret =3D backup_cow_with_offload(job, start, end, is_write_noti= fier); + ret =3D backup_cow_with_offload(job, start, dirty_end, + is_write_notifier); if (ret < 0) { job->use_copy_range =3D false; } } if (!job->use_copy_range) { - ret =3D backup_cow_with_bounce_buffer(job, start, end, is_writ= e_notifier, + ret =3D backup_cow_with_bounce_buffer(job, start, dirty_end, + is_write_notifier, error_is_read, &bounce_buf= fer); } if (ret < 0) { --=20 2.21.0