From nobody Sat Nov 8 07:31:51 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1550100292999434.98761749447385; Wed, 13 Feb 2019 15:24:52 -0800 (PST) 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 5CAC52D7EC; Wed, 13 Feb 2019 23:24:51 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 28CF95D6AA; Wed, 13 Feb 2019 23:24:51 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id DA7CB3F6E4; Wed, 13 Feb 2019 23:24:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x1DNOnXX016576 for ; Wed, 13 Feb 2019 18:24:49 -0500 Received: by smtp.corp.redhat.com (Postfix) id E397A1019627; Wed, 13 Feb 2019 23:24:49 +0000 (UTC) Received: from probe.bos.redhat.com (dhcp-17-231.bos.redhat.com [10.18.17.231]) by smtp.corp.redhat.com (Postfix) with ESMTP id 16DEC1024949; Wed, 13 Feb 2019 23:24:18 +0000 (UTC) From: John Snow To: qemu-block@nongnu.org, qemu-devel@nongnu.org Date: Wed, 13 Feb 2019 18:23:53 -0500 Message-Id: <20190213232356.21034-4-jsnow@redhat.com> In-Reply-To: <20190213232356.21034-1-jsnow@redhat.com> References: <20190213232356.21034-1-jsnow@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: Fam Zheng , Kevin Wolf , vsementsov@virtuozzo.com, Juan Quintela , libvir-list@redhat.com, "Dr. David Alan Gilbert" , Stefan Hajnoczi , Max Reitz , John Snow Subject: [libvirt] [PATCH v2 3/6] block/dirty-bitmap: change semantics of enabled predicate X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Feb 2019 23:24:51 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Currently, enabled means something like "the status of the bitmap is ACTIVE." After this patch, it should mean exclusively: "This bitmap is recording guest writes, and is allowed to do so." In many places, this is how this predicate was already used. We'll allow users to call user_locked if they're really curious about finding out if the bitmap is in use by an operation. To accommodate this, modify the create_successor routine to now explicitly disable the parent bitmap at creation time. Justifications: 1. bdrv_dirty_bitmap_status suffers no change from the lack of 1:1 parity with the new predicates because of the order in which the predicates are checked. This is now only for compatibility. 2. bdrv_set_dirty_bitmap is only used by mirror, which does not use disabled bitmaps -- all of these writes are internal usages. Therefore, we should allow writes even in the disabled state. The condition is removed. 3. bdrv_reset_dirty_bitmap Similarly, this is only used internally by mirror and migration. In these contexts it is always enabled anyway, but our API does not need to enforce this. 4. bdrv_set_dirty() is unchanged: pre-patch, it was skipping bitmaps that w= ere disabled or had a successor, while post-patch it is only skipping bitmaps that are disabled. To accommodate this, create_successor now ensures that any bitmap with a successor is explicitly disabled. 5. qcow2_store_persistent_dirty_bitmaps: This only ever wanted to check if = the bitmap was enabled or not. Theoretically if we save during an operation, this now gets set as enabled instead of disabled, but this cannot happen in practice because jobs must be finished before we close the disk. 6. block_dirty_bitmap_enable_prepare only ever cared about the literal bit, and already checked for user_locked beforehand. 7. block_dirty_bitmap_disable_prepare ditto as above. 8. init_dirty_bitmap_migration also already checks user_locked, so this call can be a simple enabled/disabled check. Signed-off-by: John Snow Reviewed-by: Eric Blake --- block/dirty-bitmap.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c index 639ebc0645..bb2e19e0d8 100644 --- a/block/dirty-bitmap.c +++ b/block/dirty-bitmap.c @@ -209,7 +209,7 @@ bool bdrv_dirty_bitmap_qmp_locked(BdrvDirtyBitmap *bitm= ap) /* Called with BQL taken. */ bool bdrv_dirty_bitmap_enabled(BdrvDirtyBitmap *bitmap) { - return !(bitmap->disabled || bitmap->successor); + return !bitmap->disabled; } =20 /* Called with BQL taken. */ @@ -264,6 +264,7 @@ int bdrv_dirty_bitmap_create_successor(BlockDriverState= *bs, =20 /* Successor will be on or off based on our current state. */ child->disabled =3D bitmap->disabled; + bitmap->disabled =3D true; =20 /* Install the successor and freeze the parent */ bitmap->successor =3D child; @@ -346,6 +347,8 @@ BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap_locked(Block= DriverState *bs, error_setg(errp, "Merging of parent and successor bitmap failed"); return NULL; } + + parent->disabled =3D successor->disabled; bdrv_release_dirty_bitmap_locked(successor); parent->successor =3D NULL; =20 @@ -542,7 +545,6 @@ int64_t bdrv_dirty_iter_next(BdrvDirtyBitmapIter *iter) void bdrv_set_dirty_bitmap_locked(BdrvDirtyBitmap *bitmap, int64_t offset, int64_t bytes) { - assert(bdrv_dirty_bitmap_enabled(bitmap)); assert(!bdrv_dirty_bitmap_readonly(bitmap)); hbitmap_set(bitmap->bitmap, offset, bytes); } @@ -559,7 +561,6 @@ void bdrv_set_dirty_bitmap(BdrvDirtyBitmap *bitmap, void bdrv_reset_dirty_bitmap_locked(BdrvDirtyBitmap *bitmap, int64_t offset, int64_t bytes) { - assert(bdrv_dirty_bitmap_enabled(bitmap)); assert(!bdrv_dirty_bitmap_readonly(bitmap)); hbitmap_reset(bitmap->bitmap, offset, bytes); } --=20 2.17.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list