From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
phrdina@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org,
lcapitulino@redhat.com, pbonzini@redhat.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH V3 1/4] block: drop bs_snapshots global variable
Date: Wed, 29 May 2013 15:54:46 +0800 [thread overview]
Message-ID: <51A5B446.7080905@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130528074649.GC13368@stefanha-thinkpad.redhat.com>
于 2013-5-28 15:46, Stefan Hajnoczi 写道:
> On Mon, May 27, 2013 at 05:25:16PM +0200, Kevin Wolf wrote:
>> Am 25.05.2013 um 05:09 hat Wenchao Xia geschrieben:
>>> From: Stefan Hajnoczi <stefanha@redhat.com>
>>>
>>> The bs_snapshots global variable points to the BlockDriverState which
>>> will be used to save vmstate. This is really a savevm.c concept but was
>>> moved into block.c:bdrv_snapshots() when it became clear that hotplug
>>> could result in a dangling pointer.
>>>
>>> While auditing the block layer's global state I came upon bs_snapshots
>>> and realized that a variable is not necessary here. Simply find the
>>> first BlockDriverState capable of internal snapshots each time this is
>>> needed.
>>>
>>> The behavior of bdrv_snapshots() is preserved across hotplug because new
>>> drives are always appended to the bdrv_states list. This means that
>>> calling the new find_vmstate_bs() function is idempotent - it returns
>>> the same BlockDriverState unless it was hot-unplugged.
>>>
>>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>> Reviewed-by: Eric Blake <eblake@redhat.com>
>>> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
>>> Signed-off-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
>>> ---
>>> block.c | 28 ----------------------------
>>> include/block/block.h | 1 -
>>> savevm.c | 19 +++++++++++++++----
>>> 3 files changed, 15 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/block.c b/block.c
>>> index 3f87489..478a3b2 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -99,9 +99,6 @@ static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
>>> static QLIST_HEAD(, BlockDriver) bdrv_drivers =
>>> QLIST_HEAD_INITIALIZER(bdrv_drivers);
>>>
>>> -/* The device to use for VM snapshots */
>>> -static BlockDriverState *bs_snapshots;
>>> -
>>> /* If non-zero, use only whitelisted block drivers */
>>> static int use_bdrv_whitelist;
>>>
>>> @@ -1357,9 +1354,6 @@ void bdrv_close(BlockDriverState *bs)
>>> notifier_list_notify(&bs->close_notifiers, bs);
>>>
>>> if (bs->drv) {
>>> - if (bs == bs_snapshots) {
>>> - bs_snapshots = NULL;
>>> - }
>>> if (bs->backing_hd) {
>>> bdrv_delete(bs->backing_hd);
>>> bs->backing_hd = NULL;
>>> @@ -1591,7 +1585,6 @@ void bdrv_delete(BlockDriverState *bs)
>>>
>>> bdrv_close(bs);
>>>
>>> - assert(bs != bs_snapshots);
>>> g_free(bs);
>>> }
>>>
>>> @@ -1635,9 +1628,6 @@ void bdrv_set_dev_ops(BlockDriverState *bs, const BlockDevOps *ops,
>>> {
>>> bs->dev_ops = ops;
>>> bs->dev_opaque = opaque;
>>> - if (bdrv_dev_has_removable_media(bs) && bs == bs_snapshots) {
>>> - bs_snapshots = NULL;
>>> - }
>>
>> This hunk isn't replaced by any other code. If I understand correctly
>> what it's doing, it prevented you from saving the VM state to a
>> removable device, which would be allowed after this patch.
>>
>> Is this a change we want to make? Why isn't it described in the commit
>> message?
>
> My understanding of this change is different. Markus is on CC so maybe
> he can confirm.
>
> The point of bs_snapshots = NULL is not to prevent you from saving
> snapshots. It's simply to reset the pointer to the next snapshottable
> device (used by bdrv_snapshots()).
>
> See the bdrv_close() hunk above which does the same thing, as well as
> bdrv_snapshots() which iterates bdrv_states and updates bs_snapshots.
>
> So what this hunk does is to reset the bdrv_snapshots() iterator when a
> removable device is hooked up to an emulated storage controller. It's
> no longer necessary since this patch drops the global state
> (bs_snapshots) and users will always iterate from scratch.
>
> The whole stateful approach was not necessary.
>
> Stefan
>
Reading the code, original logic actually forbidded saving vmstate
into a removable device, now it is possible since find_vmstate_bs()
doesn't check it. How about forbid again in find_vmstate_bs()?
--
Best Regards
Wenchao Xia
next prev parent reply other threads:[~2013-05-29 7:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-25 3:09 [Qemu-devel] [PATCH V3 0/4] qapi and snapshot code clean up in block layer Wenchao Xia
2013-05-25 3:09 ` [Qemu-devel] [PATCH V3 1/4] block: drop bs_snapshots global variable Wenchao Xia
2013-05-27 15:18 ` Kevin Wolf
2013-05-28 2:20 ` Wenchao Xia
2013-05-27 15:25 ` Kevin Wolf
2013-05-28 2:24 ` Wenchao Xia
2013-05-28 7:46 ` Stefan Hajnoczi
2013-05-29 7:54 ` Wenchao Xia [this message]
2013-05-29 9:09 ` Stefan Hajnoczi
2013-05-29 9:45 ` Wenchao Xia
2013-05-25 3:09 ` [Qemu-devel] [PATCH V3 2/4] block: move snapshot code in block.c to block/snapshot.c Wenchao Xia
2013-05-25 12:17 ` Eric Blake
2013-05-25 3:09 ` [Qemu-devel] [PATCH V3 3/4] block: move qmp and info dump related code to block/qapi.c Wenchao Xia
2013-05-25 3:09 ` [Qemu-devel] [PATCH V3 4/4] block: dump snapshot and image info to specified output Wenchao Xia
2013-05-25 12:15 ` Eric Blake
2013-05-27 15:02 ` Luiz Capitulino
2013-05-27 15:40 ` Kevin Wolf
2013-05-27 15:55 ` Luiz Capitulino
2013-05-28 2:09 ` Wenchao Xia
2013-05-27 15:41 ` [Qemu-devel] [PATCH V3 0/4] qapi and snapshot code clean up in block layer Kevin Wolf
2013-05-30 2:41 ` Wenchao Xia
2013-05-31 13:04 ` Wenchao Xia
2013-05-31 13:19 ` Luiz Capitulino
2013-06-03 2:22 ` Wenchao Xia
2013-06-04 12:46 ` Kevin Wolf
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=51A5B446.7080905@linux.vnet.ibm.com \
--to=xiawenc@linux.vnet.ibm.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=pbonzini@redhat.com \
--cc=phrdina@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.