qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Naphtali Sprei <nsprei@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Add readonly flag to -drive command
Date: Mon, 12 Oct 2009 15:24:06 +0200	[thread overview]
Message-ID: <4AD32DF6.4050100@redhat.com> (raw)
In-Reply-To: <4AD32550.8040901@redhat.com>

Am 12.10.2009 14:47, schrieb Naphtali Sprei:
> In order to safely share an image between guests (as read only drive), add a 'readonly' flag
> to the -drive command (qemu command line and monitor).
> 
> Still missing passing the read only attribute to the guest, where possible. I don't know which device types supports
> read only, and don't know how to pass this information to guests.
> 
> Also not sure what to do when qemu cannot open the file as writeable. Currently it opens it as read only.
> We might change it to give a warning or even an error.
> 
> From 6e297da79a4c015555e3927e6d28744933a31ebe Mon Sep 17 00:00:00 2001
> From: Naphtali Sprei <nsprei@redhat.com>
> Date: Mon, 12 Oct 2009 14:25:25 +0200
> Subject: [PATCH] Added readonly flag to -drive command.
>  This enables sharing same image between guests, with readonly access.
>  Implementaion mark the drive as read_only and changes the flags when actually opening the file.

Is this enough? Basically none of the block drivers know that their
image could be read-only, so we'll likely trigger some unexpected error
cases there. For a simple write I guess we'll be okay (not sure if we'll
return the right error code, though), but I have no idea what, say,
savevm would do with a read-only image.

What cases have you tested?

> TODO:
> 1. Pass the readonly attribute to the guest (write-protected drive ??)

I agree. To be useful the read-only attribute should be exposed to the
guest. I think most devices support some sort of write protection.

> 2. Re-visit the scheme where qemu open a file (silently) in read only mode when it can't open for write.
>    Now that user can specify read only (and didn't), might give a warning when not writeable, or even
>    give an error.
> 
> Signed-off-by: Naphtali Sprei <nsprei@redhat.com>
> ---
>  block.c       |   14 ++++++++++++--
>  block.h       |    1 +
>  qemu-config.c |    3 +++
>  vl.c          |    6 ++++++
>  4 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 33f3d65..01fd289 100644
> --- a/block.c
> +++ b/block.c
> @@ -335,7 +335,8 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
>      char tmp_filename[PATH_MAX];
>      char backing_filename[PATH_MAX];
>  
> -    bs->read_only = 0;
> +    /* don't mess with it, should have been zeros, anyway */
> +    /* bs->read_only = 0; */

Why leave that comment instead of just removing it if it's not necessary?

Kevin

  reply	other threads:[~2009-10-12 13:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-12 12:47 [Qemu-devel] [PATCH] Add readonly flag to -drive command Naphtali Sprei
2009-10-12 13:24 ` Kevin Wolf [this message]
2009-10-12 13:50   ` Jamie Lokier
2009-10-12 14:07     ` Kevin Wolf
2009-10-12 14:30     ` Anthony Liguori
2009-10-12 15:16       ` Jamie Lokier
2009-10-12 16:15       ` Michael Tokarev
2009-10-13  7:36         ` Kevin Wolf
2009-10-12 14:06   ` Anthony Liguori

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=4AD32DF6.4050100@redhat.com \
    --to=kwolf@redhat.com \
    --cc=nsprei@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).