From: "Daniel P. Berrange" <berrange@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: kwolf@redhat.com, stefanha@gmail.com, aliguori@us.ibm.com,
qemu-devel@nongnu.org, prerna@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 2/4] block: add a helper to change writeback mode on the fly
Date: Thu, 17 Mar 2011 14:44:56 +0000 [thread overview]
Message-ID: <20110317144455.GA15948@redhat.com> (raw)
In-Reply-To: <20110315141132.GB30710@lst.de>
On Tue, Mar 15, 2011 at 03:11:32PM +0100, Christoph Hellwig wrote:
> Add a new bdrv_change_cache that can set/clear the writeback flag
> at runtime by stopping all I/O and closing/reopening the image file.
>
> All code is based on a patch from Prerna Saxena <prerna@linux.vnet.ibm.com>
> with minimal refactoring.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
>
> +static int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
> +{
> + BlockDriver *drv = bs->drv;
> + int ret;
> +
> + if (bdrv_flags == bs->open_flags) {
> + return 0;
> + }
> +
> + /* Quiesce IO for the given block device */
> + qemu_aio_flush();
> + bdrv_flush(bs);
> +
> + bdrv_close(bs);
> + ret = bdrv_open(bs, bs->filename, bdrv_flags, drv);
> +
> + /*
> + * A failed attempt to reopen the image file must lead to 'abort()'
> + */
> + if (ret != 0) {
> + abort();
> + }
> +
> + return ret;
> +}
> +
> +int bdrv_change_cache(BlockDriverState *bs, bool enable)
> +{
> + int bdrv_flags = 0;
> +
> + bdrv_flags = bs->open_flags & ~BDRV_O_CACHE_WB;
> + if (enable) {
> + bdrv_flags |= BDRV_O_CACHE_WB;
> + }
> +
> + return bdrv_reopen(bs, bdrv_flags);
> +}
Is there any way we can manage todo this *without* closing and
re-opening the file descriptor ?
One of the things we're considering for the future is to enable
QEMU to be passed open FD(s) for its drives, from the management
system, instead of having QEMU open the files itself. This will
make it possible to have strong, per-VM selinux isolation for
disks stored on NFS. It will also make it easier to let us run
QEMU inside a private filesystem namespace (CLONE_NEWNS) and not
have to expose any files in that namespace except the QEMU binary
& a few device nodes (particularly useful for hotplug since we
won't know what files need to be visible inside the private namespace
ahead of time).
If QEMU expects to close+reopen any of its disks at any time the
guest requests, this will complicate life somewhat
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2011-03-17 14:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 14:10 [Qemu-devel] [PATCH, RFC 0/4] allow guest control of the volatile write cache Christoph Hellwig
2011-03-15 14:11 ` [Qemu-devel] [PATCH 1/4] block: clarify the meaning of BDRV_O_NOCACHE Christoph Hellwig
2011-03-16 9:42 ` [Qemu-devel] " Stefan Hajnoczi
2011-03-16 9:55 ` Kevin Wolf
2011-03-16 14:08 ` Christoph Hellwig
2011-03-16 17:00 ` Stefan Hajnoczi
2011-03-17 9:07 ` Kevin Wolf
2011-03-17 9:18 ` Stefan Hajnoczi
2011-03-15 14:11 ` [Qemu-devel] [PATCH 2/4] block: add a helper to change writeback mode on the fly Christoph Hellwig
2011-03-15 14:11 ` [Qemu-devel] [PATCH 3/4] ide: wire up setfeatures cache control Christoph Hellwig
2011-03-15 14:11 ` [Qemu-devel] [PATCH 4/4] virtio-blk: add runtime " Christoph Hellwig
2011-03-16 9:49 ` [Qemu-devel] Re: [PATCH 2/4] block: add a helper to change writeback mode on the fly Stefan Hajnoczi
2011-03-16 9:59 ` Kevin Wolf
2011-03-17 14:44 ` Daniel P. Berrange [this message]
2011-03-17 15:11 ` [Qemu-devel] " Kevin Wolf
2011-03-17 16:44 ` Stefan Hajnoczi
2011-03-19 8:28 ` Blue Swirl
2011-03-15 14:16 ` [Qemu-devel] [PATCH, RFC] virtio_blk: add cache control support Christoph Hellwig
2011-03-16 4:09 ` [Qemu-devel] " Rusty Russell
2011-03-16 14:09 ` Christoph Hellwig
2011-03-17 5:06 ` Rusty Russell
2011-03-17 14:21 ` Christoph Hellwig
2011-03-24 0:11 ` Rusty Russell
2011-03-24 3:11 ` Anthony Liguori
2011-03-24 3:05 ` Anthony Liguori
2011-03-24 9:54 ` Christian Borntraeger
2011-03-25 5:08 ` Rusty Russell
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=20110317144455.GA15948@redhat.com \
--to=berrange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=hch@lst.de \
--cc=kwolf@redhat.com \
--cc=prerna@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).