All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: phrdina@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org,
	lcapitulino@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
	pbonzini@redhat.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH V3 1/4] block: drop bs_snapshots global variable
Date: Tue, 28 May 2013 10:20:12 +0800	[thread overview]
Message-ID: <51A4145C.8040908@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130527151852.GE2373@dhcp-200-207.str.redhat.com>

于 2013-5-27 23:18, Kevin Wolf 写道:
> 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>
>
> I am not totally convinced by this approach, especially when it's nowhere
> documented that the order of BDSes in the list is important. However, I
> think the current code is suboptimal as well, so I'll apply this for
> now.
>
> What we really want is this: savevm lets you choose which image to save
> the VM state to, and if you don't specify one, it automatically picks
> one like today. loadvm checks all images and loads the VM state from the
> image that has the VM state for this snapshot. If loadvm finds that it's
> not exactly one image that has a VM state, this is an error condition.
>
> Is anyone interested in implementing this?
>
> Kevin
>
   I think that can came up after Pavel's savevm transaction, which
add parameter telling which image to save vmstate. This patch simply
keep what it is now not touching that part.



-- 
Best Regards

Wenchao Xia

  reply	other threads:[~2013-05-28  2:20 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 [this message]
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
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=51A4145C.8040908@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.