All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Supriya Kannery <supriyak@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [V2 3/3] Command "block_set" for dynamic block params change
Date: Mon, 20 Jun 2011 16:34:20 +0200	[thread overview]
Message-ID: <4DFF5A6C.8060301@redhat.com> (raw)
In-Reply-To: <20110617163806.2933.39799.sendpatchset@skannery>

Am 17.06.2011 18:38, schrieb Supriya Kannery:
> New command "block_set" added for dynamically changing any of the block 
> device parameters. For now, dynamic setting of hostcache params using this 
> command is implemented. Other block device parameters, can be integrated 
> in similar lines.
> 
> Signed-off-by: Supriya Kannery <supriyak@in.ibm.com>

Coding style is off in this one as well.

> Index: qemu/blockdev.c
> ===================================================================
> --- qemu.orig/blockdev.c
> +++ qemu/blockdev.c
> @@ -797,3 +797,35 @@ int do_block_resize(Monitor *mon, const 
>  
>      return 0;
>  }
> +
> +
> +/*
> + * Handle changes to block device settings, like hostcache,
> + * while guest is running.
> +*/
> +int do_block_set(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +	const char *device = qdict_get_str(qdict, "device");
> +	const char *name = qdict_get_str(qdict, "name");
> +	int enable = qdict_get_bool(qdict, "enable");
> +	BlockDriverState *bs;
> +
> +	bs = bdrv_find(device);
> +	if (!bs) {
> +		qerror_report(QERR_DEVICE_NOT_FOUND, device);
> +		return -1;
> +	}
> +
> +	if (!(strcmp(name, "hostcache"))) {

The bracket after ! isn't necessary.

> +		if (bdrv_is_inserted(bs)) {
> +			/* cache change applicable only if device inserted */
> +			return bdrv_change_hostcache(bs, enable);
> +		} else {
> +			qerror_report(QERR_DEVICE_NOT_INSERTED, device);
> +			return -1;
> +		}

I'm not so sure about this one. Why shouldn't I change the cache mode
for a device which is currently? The next thing I want to do could be
inserting a medium and using it with the new cache mode.

> +	}
> +
> +	return 0;
> +}
> +
> Index: qemu/block.c
> ===================================================================
> --- qemu.orig/block.c
> +++ qemu/block.c
> @@ -651,6 +651,33 @@ unlink_and_fail:
>      return ret;
>  }
>  
> +int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
> +{
> +	BlockDriver *drv = bs->drv;
> +	int ret = 0;
> +
> +	/* No need to reopen as no change in flags */
> +	if (bdrv_flags == bs->open_flags)
> +		return 0;

There could be other reasons for reopening besides changing flags, e.g.
invalidating cached metadata.

> +
> +	/* Quiesce IO for the given block device */
> +	qemu_aio_flush();
> +	bdrv_flush(bs);

Missing error handling.

> +
> +	bdrv_close(bs);

Here, too.

> +	ret = bdrv_open(bs, bs->filename, bdrv_flags, drv);
> +
> +	/*
> +	* A failed attempt to reopen the image file must lead to 'abort()'
> +	*/
> +	if (ret != 0) {
> +		qerror_report(QERR_REOPEN_FILE_FAILED, bs->filename);
> +		abort();
> +	}

Maybe we can retry with the old flags at least before aborting?

Also I would like to see a (Linux specific) version that uses the old fd
for the reopen, so that we can handle files that aren't accessible with
their old name any more. This would mean adding a .bdrv_reopen callback
in raw-posix.

> +
> +	return ret;
> +}
> +
>  void bdrv_close(BlockDriverState *bs)
>  {
>      if (bs->drv) {
> @@ -691,6 +718,20 @@ void bdrv_close_all(void)
>      }
>  }
>  
> +int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache)
> +{
> +	int bdrv_flags = bs->open_flags;
> +
> +	/* set hostcache flags (without changing WCE/flush bits) */
> +	if (enable_host_cache)
> +		bdrv_flags &= ~BDRV_O_NOCACHE;
> +	else
> +		bdrv_flags |= BDRV_O_NOCACHE;
> +
> +	/* Reopen file with changed set of flags */
> +	return bdrv_reopen(bs, bdrv_flags);
> +}

Hm, interesting. Now we can get a O_DIRECT | O_SYNC mode with the
monitor. We should probably expose the same functionality for the
command line, too.

Kevin

  parent reply	other threads:[~2011-06-20 14:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-17 16:37 [Qemu-devel] [V3 0/3]block: Dynamically change hostcache setting using new "block_set" command Supriya Kannery
2011-06-17 16:37 ` [Qemu-devel] [V3 1/3] Enhance "info block" to display hostcache setting Supriya Kannery
2011-06-20 14:23   ` Kevin Wolf
2011-06-22 14:59     ` Supriya Kannery
2011-06-17 16:37 ` [Qemu-devel] [V3 2/3] Error classes for file reopen and device insertion Supriya Kannery
2011-06-20 14:23   ` Kevin Wolf
2011-06-17 16:38 ` [Qemu-devel] [V2 3/3] Command "block_set" for dynamic block params change Supriya Kannery
2011-06-17 17:23   ` [Qemu-devel] [V2 3/3] <Resend> " Supriya Kannery
2011-06-20 14:34   ` Kevin Wolf [this message]
2011-06-22 16:09     ` [Qemu-devel] [V2 3/3] " Supriya Kannery
2011-06-27  8:18       ` 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=4DFF5A6C.8060301@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hch@lst.de \
    --cc=qemu-devel@nongnu.org \
    --cc=supriyak@linux.vnet.ibm.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.