qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).