From: John Snow <jsnow@redhat.com>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
vsementsov@virtuozzo.com, Juan Quintela <quintela@redhat.com>,
eblake@redhat.com, Max Reitz <mreitz@redhat.com>,
libvir-list@redhat.com,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
John Snow <jsnow@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>, Fam Zheng <fam@euphon.net>
Subject: [Qemu-devel] [PATCH v3 04/10] block/dirty-bitmap: change semantics of enabled predicate
Date: Fri, 22 Feb 2019 19:06:08 -0500 [thread overview]
Message-ID: <20190223000614.13894-5-jsnow@redhat.com> (raw)
In-Reply-To: <20190223000614.13894-1-jsnow@redhat.com>
Currently, the enabled predicate means something like:
"the QAPI 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.
Internal usages of the bitmap QPI can call user_locked to find 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() is unchanged: pre-patch, it was skipping bitmaps that were
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.
3. qcow2_store_persistent_dirty_bitmaps: No functional change. This function
cares only about the literal enabled bit, and makes no effort to check if
the bitmap is in-use or not. After this patch there are still no ways to
produce an enabled bitmap with a successor.
4. block_dirty_bitmap_enable_prepare
block_dirty_bitmap_disable_prepare
init_dirty_bitmap_migration
nbd_export_new
These functions care about the literal enabled bit,
and already check user_locked separately.
Signed-off-by: John Snow <jsnow@redhat.com>
---
block/dirty-bitmap.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 9ea5738420..976831e765 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -209,7 +209,7 @@ bool bdrv_dirty_bitmap_qmp_locked(BdrvDirtyBitmap *bitmap)
/* Called with BQL taken. */
bool bdrv_dirty_bitmap_enabled(BdrvDirtyBitmap *bitmap)
{
- return !(bitmap->disabled || bitmap->successor);
+ return !bitmap->disabled;
}
/* Called with BQL taken. */
@@ -236,6 +236,7 @@ static bool bdrv_dirty_bitmap_recording(BdrvDirtyBitmap *bitmap)
/**
* Create a successor bitmap destined to replace this bitmap after an operation.
* Requires that the bitmap is not user_locked and has no successor.
+ * The successor will be enabled if the parent bitmap was.
* Called with BQL taken.
*/
int bdrv_dirty_bitmap_create_successor(BlockDriverState *bs,
@@ -264,6 +265,7 @@ int bdrv_dirty_bitmap_create_successor(BlockDriverState *bs,
/* Successor will be on or off based on our current state. */
child->disabled = bitmap->disabled;
+ bitmap->disabled = true;
/* Install the successor and freeze the parent */
bitmap->successor = child;
@@ -328,7 +330,8 @@ BdrvDirtyBitmap *bdrv_dirty_bitmap_abdicate(BlockDriverState *bs,
/**
* In cases of failure where we can no longer safely delete the parent,
* we may wish to re-join the parent and child/successor.
- * The merged parent will not be user_locked, nor explicitly re-enabled.
+ * The merged parent will not be user_locked.
+ * The marged parent will be enabled if and only if the successor was enabled.
* Called within bdrv_dirty_bitmap_lock..unlock and with BQL taken.
*/
BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap_locked(BlockDriverState *bs,
@@ -346,6 +349,8 @@ BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap_locked(BlockDriverState *bs,
error_setg(errp, "Merging of parent and successor bitmap failed");
return NULL;
}
+
+ parent->disabled = successor->disabled;
bdrv_release_dirty_bitmap_locked(successor);
parent->successor = NULL;
--
2.17.2
next prev parent reply other threads:[~2019-02-23 0:07 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-23 0:06 [Qemu-devel] [PATCH v3 00/10] dirty-bitmaps: deprecate @status field John Snow
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 01/10] block/dirty-bitmap: add recording and busy properties John Snow
2019-02-23 20:06 ` Eric Blake
2019-02-25 6:23 ` Vladimir Sementsov-Ogievskiy
2019-02-25 15:01 ` Vladimir Sementsov-Ogievskiy
2019-02-25 15:08 ` Eric Blake
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 02/10] block/dirty-bitmaps: rename frozen predicate helper John Snow
2019-02-23 21:10 ` Eric Blake
2019-02-25 7:01 ` Vladimir Sementsov-Ogievskiy
2019-02-25 20:09 ` John Snow
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 03/10] block/dirty-bitmap: remove set/reset assertions against enabled bit John Snow
2019-02-23 21:11 ` Eric Blake
2019-02-25 7:09 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` John Snow [this message]
2019-02-23 21:14 ` [Qemu-devel] [PATCH v3 04/10] block/dirty-bitmap: change semantics of enabled predicate Eric Blake
2019-02-25 7:39 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 05/10] nbd: change error checking order for bitmaps John Snow
2019-02-23 21:29 ` Eric Blake
2019-02-25 7:44 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 06/10] block/dirty-bitmap: explicitly lock bitmaps with successors John Snow
2019-02-25 7:48 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 07/10] block/dirty-bitmaps: unify qmp_locked and user_locked calls John Snow
2019-02-23 21:32 ` Eric Blake
2019-02-25 12:03 ` Vladimir Sementsov-Ogievskiy
2019-02-25 20:37 ` John Snow
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 08/10] block/dirty-bitmaps: move comment block John Snow
2019-02-23 21:32 ` Eric Blake
2019-02-25 12:11 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 09/10] blockdev: remove unused paio parameter documentation John Snow
2019-02-23 21:33 ` Eric Blake
2019-02-25 12:20 ` Vladimir Sementsov-Ogievskiy
2019-02-23 0:06 ` [Qemu-devel] [PATCH v3 10/10] iotests: add busy/recording bit test to 124 John Snow
2019-02-23 22:06 ` Eric Blake
2019-02-25 20:29 ` John Snow
2019-02-25 22:08 ` [Qemu-devel] [PATCH v3 00/10] dirty-bitmaps: deprecate @status field John Snow
2019-02-27 17:45 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190223000614.13894-5-jsnow@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=kwolf@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).