From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: John Snow <jsnow@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: Fam Zheng <fam@euphon.net>,
Peter Maydell <peter.maydell@linaro.org>,
aihua liang <aliang@redhat.com>,
Juan Quintela <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] migration/dirty-bitmaps: change bitmap enumeration method
Date: Thu, 16 May 2019 10:12:30 +0000 [thread overview]
Message-ID: <72986b5d-0772-abfb-2c99-97470e8fd3da@virtuozzo.com> (raw)
In-Reply-To: <20190514201926.10407-1-jsnow@redhat.com>
14.05.2019 23:19, John Snow wrote:
> Shift from looking at every root BDS to *every* BDS. This will migrate
> bitmaps that are attached to blockdev created nodes instead of just ones
> attached to emulated storage devices.
>
> Note that this will not migrate anonymous or internal-use bitmaps, as
> those are defined as having no name.
>
> This will also fix the Coverity issues Peter Maydell has been asking
> about for the past several releases, as well as fixing a real bug.
>
> Reported-by: Peter Maydell <peter.maydell@linaro.org>
> Reported-by: Coverity 😅
> Reported-by: aihua liang <aliang@redhat.com>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1652490
> Fixes: Coverity CID 1390625
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> migration/block-dirty-bitmap.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
> index d1bb863cb6..4a896a09eb 100644
> --- a/migration/block-dirty-bitmap.c
> +++ b/migration/block-dirty-bitmap.c
> @@ -273,7 +273,6 @@ static int init_dirty_bitmap_migration(void)
> BlockDriverState *bs;
> BdrvDirtyBitmap *bitmap;
> DirtyBitmapMigBitmapState *dbms;
> - BdrvNextIterator it;
> Error *local_err = NULL;
>
> dirty_bitmap_mig_state.bulk_completed = false;
> @@ -281,13 +280,8 @@ static int init_dirty_bitmap_migration(void)
> dirty_bitmap_mig_state.prev_bitmap = NULL;
> dirty_bitmap_mig_state.no_bitmaps = false;
>
> - for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
> - const char *drive_name = bdrv_get_device_or_node_name(bs);
> -
> - /* skip automatically inserted nodes */
> - while (bs && bs->drv && bs->implicit) {
> - bs = backing_bs(bs);
> - }
hm, so, after the patch, for implicitly-filtered nodes we'll have node_name instead of device name..
But, on the other, hand, if we have implicitly-filtered node on target, we were doing wrong thing anyway,
as dirty_bitmap_load_header don't skip implicit nodes.
> + for (bs = bdrv_next_all_states(NULL); bs; bs = bdrv_next_all_states(bs)) {
As I understand, difference with bdrv_next_node is that we don't skip unnamed nodes [...]
> + const char *name = bdrv_get_device_or_node_name(bs);
>
> for (bitmap = bdrv_dirty_bitmap_next(bs, NULL); bitmap;
> bitmap = bdrv_dirty_bitmap_next(bs, bitmap))
> @@ -296,7 +290,7 @@ static int init_dirty_bitmap_migration(void)
> continue;
> }
>
> - if (drive_name == NULL) {
> + if (!name || strcmp(name, "") == 0) {
[...] to do this (may be paranoiac, but why not?) check
> error_report("Found bitmap '%s' in unnamed node %p. It can't "
> "be migrated", bdrv_dirty_bitmap_name(bitmap), bs);
> goto fail;
> @@ -313,7 +307,7 @@ static int init_dirty_bitmap_migration(void)
>
> dbms = g_new0(DirtyBitmapMigBitmapState, 1);
> dbms->bs = bs;
> - dbms->node_name = drive_name;
> + dbms->node_name = name;
> dbms->bitmap = bitmap;
> dbms->total_sectors = bdrv_nb_sectors(bs);
> dbms->sectors_per_chunk = CHUNK_SIZE * 8 *
>
There is still some mess about device name vs node name, and I don't know, could we somehow
solve it, but patch looks OK for me anyway:
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
--
Best regards,
Vladimir
next prev parent reply other threads:[~2019-05-16 10:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 20:19 [Qemu-devel] [PATCH v2] migration/dirty-bitmaps: change bitmap enumeration method John Snow
2019-05-16 10:12 ` Vladimir Sementsov-Ogievskiy [this message]
2019-05-16 19:03 ` John Snow
2019-05-17 10:22 ` Vladimir Sementsov-Ogievskiy
2019-05-20 9:27 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-05-20 10:37 ` Vladimir Sementsov-Ogievskiy
2019-05-20 16:43 ` John Snow
2019-12-06 22:31 ` Vladimir Sementsov-Ogievskiy
2019-12-09 15:22 ` John Snow
2019-12-09 15:26 ` John Snow
2019-12-09 15:45 ` John Snow
2019-12-09 17:17 ` Vladimir Sementsov-Ogievskiy
2019-12-09 18:15 ` John Snow
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=72986b5d-0772-abfb-2c99-97470e8fd3da@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=aliang@redhat.com \
--cc=dgilbert@redhat.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.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).