From: John Snow <jsnow@redhat.com>
To: qemu-devel@nongnu.org
Cc: John Snow <jsnow@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-block@nongnu.org, Fam Zheng <fam@euphon.net>,
eblake@redhat.com, vsementsov@virtuozzo.com,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: [Qemu-devel] [PATCH 3/5] block/dirty-bitmap: change semantics of enabled predicate
Date: Mon, 11 Feb 2019 20:02:46 -0500 [thread overview]
Message-ID: <20190212010248.11056-4-jsnow@redhat.com> (raw)
In-Reply-To: <20190212010248.11056-1-jsnow@redhat.com>
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 will skip recording writes from the guest here if
we are disabled OR if we had a successor, which now changes.
Accommodate the change by explicitly disabling bitmaps with successors.
5. qcow2/dirty-bitmap: 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.
6. block_dirty_bitmap_enable_prepare only ever cared if 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.
---
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 dbe2d97d3f..1a433130ff 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. */
@@ -264,6 +264,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;
@@ -346,6 +347,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;
@@ -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);
}
--
2.17.2
next prev parent reply other threads:[~2019-02-12 1:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 1:02 [Qemu-devel] [PATCH 0/5] dirty-bitmaps: deprecate @status field John Snow
2019-02-12 1:02 ` [Qemu-devel] [PATCH 1/5] block/dirty-bitmap: add recording and busy properties John Snow
2019-02-12 18:17 ` Eric Blake
2019-02-12 18:23 ` John Snow
2019-02-13 9:31 ` Vladimir Sementsov-Ogievskiy
2019-02-12 1:02 ` [Qemu-devel] [PATCH 2/5] block/dirty-bitmaps: rename frozen predicate helper John Snow
2019-02-12 18:26 ` Eric Blake
2019-02-12 18:30 ` John Snow
2019-02-12 1:02 ` John Snow [this message]
2019-02-12 18:58 ` [Qemu-devel] [PATCH 3/5] block/dirty-bitmap: change semantics of enabled predicate Eric Blake
2019-02-12 19:03 ` John Snow
2019-02-12 1:02 ` [Qemu-devel] [PATCH 4/5] block/dirty-bitmap: explicitly lock bitmaps with successors John Snow
2019-02-12 19:18 ` Eric Blake
2019-02-12 1:02 ` [Qemu-devel] [PATCH 5/5] block/dirty-bitmaps: unify qmp_locked and user_locked calls John Snow
2019-02-12 19:27 ` Eric Blake
2019-02-12 19:33 ` John Snow
2019-02-12 18:12 ` [Qemu-devel] [PATCH 0/5] dirty-bitmaps: deprecate @status field Eric Blake
2019-02-12 18:15 ` John Snow
2019-02-13 19:27 ` Vladimir Sementsov-Ogievskiy
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=20190212010248.11056-4-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=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).